[Bug libc/14958] Concurrent reader deadlock in pthread_rwlock_rdlock()

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14958

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2012-12-15 05:15:58 UTC ---
Confirmed. I don't see a need for more debugging/trace data. What's going on is
very clear upon reading the original report and test case. I see two potential
fixes:

1. The easy way is to just always use broadcast wakes and let readers and
writers duke it out for who gets the lock next. NPTL's synchronization
primitives are riddled with bugs from trying to be too smart (avoiding spurious
wakes, etc.) and missing important corner cases, and I would not be sad to see
all this ripped out in favor of something that's definitively robust; however,
I recognize I'm probably in the minority here.

2. The way that's harder to get right but that should give better performance
is for the reader that "steals" the lock from waiting writers to detect this
situation and broadcast wake the futex so that all the other waiting readers
also wake up and get a chance to obtain read locks. It seems highly nontrivial
to get all the corner cases right here, especially since waiting writers can be
performing a timedlock operation and could be gone by the time the reader
"steals" the lock from them.

I also confirmed that we don't have a corresponding bug in musl (which uses
approach #1 above).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.