Re: pthread condvars and priority inheritance

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

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

> Darren Hart's PI work for condvars has to be updated in some way
> to the new implementation of condvars.
> 

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?

> Bug 11588 is the right place to track status.
> 
> I recommend having detailed discussions on libc-alpha, and only
> posting status updates or consensus conclusions in the bug, that
> way it's easier to follow the status.
> 

Thanks, I will