Re: pthread condvars and priority inheritance

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2017-09-26 at 22:21 +0000, Rodriguez, Sergio SF wrote:
> On Mon, 2017-09-25 at 22:21 -0600, Carlos O'Donell wrote:
> > On 09/25/2017 06:05 PM, Rodriguez, Sergio SF wrote:
> 
> > > 
> 
> > > Hi everyone,
> 
> > > 
> 
> > > I was looking at the bug 
> 
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=11588 and was
> 
> > > wondering
> 
> > > if someone on the glibc community is looking at this, or if the bug
> 
> > > is
> 
> > > being tracked somewhere else?
> 
> > Nobody I know is working on this issue right now.
> 
> > 
> 
> > Torvald's improved condition variables was the most recent work.
> 
> > 
> 
> I been looking at the newest condvar implementation
> and in the bug thread
> Torvald Riegel lists the main issues there, specially the one in the
> fifth bullet where waiter priority needs to be boosted in order to
> notify signaler that they have been woken up. Afaik, current kernel
> futex operation does not have such functionality for waiter to boost
> priority during futex wait period. Was there any thought or discussion
> on enhancing the kernel futex?
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=11588#c53

Latest status AFAIK is what got discussed at last year's real-time
summit:
https://wiki.linuxfoundation.org/realtime/events/rt-summit2016/schedule
https://www.youtube.com/playlist?list=PLbzoR-pLrL6oauKOYMdNjN9RuTSmC6nfR

Thomas Gleixner, Peter Zijlstra, and I were talking about meeting and
brain-storming about revising futexes, but I didn't end up having any
time for that so far.  I believe this needs new futex
operations/functionality, given all the POSIX and RT constraints we
have.

> Understood. The previous work from Darren is this right?
> 
> https://sourceware.org/bugzilla/attachment.cgi?id=7687
> 
> It was to fix a potential scenario that can hit an unbounded
> priority inversion on an internal condvar lock used in
> pthread_cond_wait() in previous condvar implementation. The new condvar
> has an internal lock used in pthread_cond_signal() and that can have
> similar issue. A similar work might be doable. It seems to me the only
> constraint is the pthread_cond_t structure already ran out of space for
> a 32-bit field for the internal lock for storing the TID for the
> FUTEX_LOCK_PI operation which was used in Darrens's PI work. Is there
> something I might be missing?

The ABA on 32b futexes is one issue; if we had a 64b futex, ideally one
that can wake up more selectively, we could avoid the need to do
blocking.  I explained the trade-offs in more detail in my RT Summit
talk.