This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/21083] robust timed lock may leave other waiters no chance to wake up


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]