[Bug nptl/11588] pthread condvars are not priority inheritance aware

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=11588

--- Comment #53 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Darren Hart from comment #50)
> Torvald, I'm reading up (again :-) ) on the issues you've raised from the
> Austin Group and building context on the use of the sequence locks, etc.
> Would you share your implementation with me so I can see what kinds of
> changes are being considered and help building support for the PI cases?

I'm in the process of cleaning up the current (second) implementation, and will
share it on libc-alpha once that is done.

> Regarding boosting waiters for sending signals. Current futex PI boosting is
> based on the Linux kernel rtmutex. Can you elaborate on the what/why in your
> statement:
> 
> > Essentially, we need to boost the priority of waiters that have to wake up from a 
> > futex that is used to send signals, and have to confirm that they have woken up.
> 

In a nutshell, the problem goes like this:
* Due to having to wake up with ordering constraints, the condition that a
futex needs to cover is not an on/off thing like a mutex, but a sequence, in an
abstract sense.  If you need to wake at position N, all 0..N waiters can
consume.
* Futexes provide no guarantees regarding the order in which waiters enqueue
and ware woken (eg, no FIFO).
* Futexes are 32b, so if one represents the ordering sequence with counting,
there is some chance of a 32b wrap around and an ABA issue on the futex
comparison.  That may be unlikely to hit, but I'm not really comfortable
putting such an ABA issue into released code knowingly.
* My previous attempt of a condvar suffered a performance problem because one
can't know whether a futex wake-up was spurious or not; if one doesn't know,
one needs to conservatively add a fake futex wake-up.
* In this implementation, one can deal with the ABA issue by quiescing the
condvar.  But for this to be possible with PI, one needs to boost the priority
of waiters when sending a signal.  I don't know how to do that with the current
futex PI ops.
* My current attempt builds two groups that waiters wait on, complete with
separate futexes per group.  That avoids performance issues of the former
simpler algorithm, but now we need to quiesce each group before we can reuse
its memory (which we need to do because of process-shared).  So similar PI
problem as before.

Specifically, the problem for PI is thus that we have waiters blocked on a
futex that is not an exclusive lock.  We need to be able to send them signals
and cause them to confirm that they have woken up.  Thus, their priorities must
be boosted at least for as long as they need to confirm the wake-up.  If we
could have something like a shared lock (ie, rwlock) with PI support, all
waiters that are about to block on the signal/condvar futex could acquire a
readlock and be boosted by a high-prio wrlock writer.  But I don't know whether
we can build that with the current futex PI ops.

The problem is easier for the non-process-shared case because then we can just
allocate additional memory and, for example, build our own userspace wait
queues, in which boosting can be done with an exclusive lock.

-- 
You are receiving this mail because:
You are on the CC list for the bug.