Re: [PATCH 0/6][BZ #11588] pi-condvars: add priority inheritance for pthread_cond_* internal lock

[Rich Felker <dalias at libc dot org>]

On Tue, Aug 19, 2014 at 09:58:29PM +0200, Torvald Riegel wrote:
> On Mon, 2014-08-18 at 18:17 -0400, Rich Felker wrote:
> > On Mon, Aug 18, 2014 at 11:53:18PM +0200, Torvald Riegel wrote:
> > > On Mon, 2014-08-18 at 17:41 -0400, Rich Felker wrote:
> > > > On Mon, Aug 18, 2014 at 11:14:19PM +0200, Torvald Riegel wrote:
> > > > > On Tue, 2014-07-29 at 19:31 -0500, gratian.crisan@ni.com wrote:
> > > > > > Torvald Riegel made us aware of the new POSIX changes related to condvars
> > > > > > (http://austingroupbugs.net/view.php?id=609) and C++11 clarification
> > > > > > (http://cplusplus.github.com/LWG/lwg-active.html#2190)
> > > > > > We believe we can work on these issues in parallel and if they end up
> > > > > > colliding we will fix it.
> > > > > 
> > > > > I've asked the Austin Group about the current status of #609.  It seems
> > > > > they want the stronger ordering guarantees:
> > > > > http://austingroupbugs.net/view.php?id=609#c2349
> > > > > 
> > > > > I have an implementation that fulfills these guarantees, but I don't
> > > > > think it's possible to fully implement PI with the stronger guarantees
> > > > > and the futex operations that we currently have.  The possible options
> > 
> > BTW, does the current implementation, or your new one pending, address
> > self-synchronized destruction, i.e.
> > 
> > "It shall be safe to destroy an initialized condition variable upon
> > which no threads are currently blocked."
> 
> The new one does fulfill that requirement (well, the requirement is not
> completely specified, but a cond_signal won't do any harm after it has
> woken up a waiter).  The general futex issue (futex_wakes hitting
> possibly reused memory) still applies, of course.

Nice.

BTW, while FUTEX_WAKE on possibly-reused memory seems harmless to me
(unless you have code relying on the successful return value of
futex_wait being distinct from EAGAIN), FUTEX_REQUEUE on possibly
reused memory seems potentially dangerous. I haven't worked out the
details except to reason that FUTEX_REQUEUE is safe as long as the
thread performing the requeue operation holds the lock that the target
will be requeued to.

> > > > > that I see are:
> > > > > * Accept potential ABA issues (e.g., a lost wake-up if you do exactly
> > > > > 2^32 signals after a wait).
> > > > > * Accept that there's no PI every 2^32 wait calls (maybe that number can
> > > > > be increased somewhat, but this depends on the interleaving of
> > > > > wait/signal calls I believe).
> > > > > * Don't support PI on process-shared condvars, so that we can boost the
> > > > > priority of waiters with per-waiter PI mutexes.  More overhead.
> > > > 
> > > > Is there any documentation on the current glibc design and how it
> > > > avoids the 2^32 ABA issue with sequence numbers?
> > > 
> > > The current algorithm doesn't prevent the ABA issue.
> > 
> > Do you have an in-progress new one that does, though?
> 
> The algorithm I have has no ABA issue.

Looking forward to seeing what you came up with!

Rich