This is the mail archive of the libc-alpha@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]

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


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
> 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? I wasn't aware that
it was avoiding this issue. I'm interested both from a standpoint of
fixing the sequence number wrapping issue in my implementation in musl
(in code that's only used for the process-shared case), and possibly
being able to offer ideas for how the glibc design could be adapted
for PI.

FYI the new cond var implementation I have in musl can definitely be
extended to support PI on the internal locks, and it has no sequence
number issues, but it's also not compatible with process-shared cond
vars.

> What would be everyone's preference?

For the second option, if you can identify the sequence number at
which there's going to be an issue and where you could solve it by
refraining from using PI, why not do this instead: On that particular
signal/broadcast operation, make it always behave as a broadcast
(spurious wakes are allowed) and synchronize with all waiters, waiting
for them to reach the point where they're ready to block on the mutex
before the signal/broadcast function returns? For non-PI, this would
have very bad priority-related consequences, but with PI, I think
those problems are avoided. Naturally this one (one in 2^32) call
would be more expensive than typical signals/waits, but it should
work.

> Note that if we had 64b futexes, the first two options would both have
> 2^64 instead of 2^32, so both would be okay in practice.

Having 64-bit futexes would be nice for various reasons, and I think
it would be nice to start pushing the kernel folks to add them now
rather than later. I don't think it's practical to make the
implementation depend on them now, but if we can get them added, it
might be practical to use them a few years down the road once they're
widely deployed.

Rich


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