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

["daniel.stodden at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #5 from Daniel Stodden <daniel.stodden at gmail dot com> 2012-12-17 09:19:31 UTC ---
Rich, I pushed a candidate fix to
https://github.com/dns42/glibc/commit/b7725621b5e2101d4218be0d09bd55a67b4d3512

It explores variant 1 for upstream.

Code presently looks correct to me, but I won't get to test it before later.
I'll post an update accordingly :)

Additional comments for discussion:

 - Note that prerequisites can be checked comparatively precisely.
   Possibly more precisely than you anticipated, taking
   __nr_readers_queued, __nr_writers_queued and __nr_readers
   into account, all at the same time.

 - This works because both queues need to come together, then
   preempted, any other case looks clean to me.

   All queued loops take the ll lock and atomically decrement, then
   succeed. So the whole combination of __nr_*_queued and __nr_readers
   can work as a discriminant.

 - As you mentioned, the timedlock cases indeed deserve special
   attention.

   I think the way they've been written would render the assumptions 
   made by the above patch correct as well.

   But only if rwlock_timedlock calls are really correct.

   Can it be that lll_futex_timed_wait does *not*
   leave an inherent race between timeout and a (too-)late wakeup call?
   In the same way pthread_cond_timedwait must?

   I'm not a futex-expert, but the problem here is that I currently
   don't believe this is even possible. In other words: How does
   present pthread_rwlock_unlock tell that any of __nr_writers_queued
   have been woken up before timing out?

   I almost suspect it can't, doesn't, and -- since timedrwlock makes 
   no attempt to restart the queue on timeout either,
   suffers from a similar race. But this would probably belong into
   another ticket.

   Apologies in advance if I'm mistaken.

-- 
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.