Re: pthread condvars and priority inheritance

["Rodriguez, Sergio SF" <sergio dot sf dot rodriguez at intel dot com>]

On Wed, 2017-10-04 at 14:09 +0200, Torvald Riegel wrote:
> 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/schedu
> le
> https://www.youtube.com/playlist?list=PLbzoR-pLrL6oauKOYMdNjN9RuTSmC6
> nfR
> 
> 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.
> 

Okay. Just make sure I understood correctly. I am assuming if we had
64b futex, then we would not need waiter groups as we have currently as
you could embed some info in the extra space in the 64b futex and use
that info to wake up waiters in more ordered sequence. As a result,
quiescent and locking would not be needed. Is that right?