This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/21083] robust timed lock may leave other waiters no chance to wake up
- From: "triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 01 Nov 2017 16:24:26 +0000
- Subject: [Bug nptl/21083] robust timed lock may leave other waiters no chance to wake up
- Auto-submitted: auto-generated
- References: <bug-21083-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21083
Torvald Riegel <triegel at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |triegel at redhat dot com
--- Comment #4 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to ma.jiang from comment #2)
> (In reply to Carlos O'Donell from comment #1)
>
> > When you say "latest glibc sources" do you mean that you tested on master?
> > How recently?
> The patch is for glibc-2.24. I checked the trunk code just now, the bug
> still exist. I have not write a testcase to reproduce the bug, it's quite
> hard(Although the bug logic is clear)...
I believe this is fixed in master(/trunk). Please have a look at what we do
with assume_other_futex_waiters: If we ever potentially share FUTEX_WAITERS
with another thread (C in your example), then after the futex operation we make
sure to set this flag in any case. This happens either when acquiring the
mutex (in which case we'll notice this during unlock and wake up C), or when
not being able to acquire it, in which case there must be another owner that
interfered and we delegate wake-up responsibilities to that other owner by
setting FUTEX_WAITERS.
--
You are receiving this mail because:
You are on the CC list for the bug.