Re: pthread condvars and priority inheritance

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

On Wed, 2017-10-11 at 09:20 -0700, Rodriguez, Sergio SF wrote:
> On Tue, 2017-10-10 at 15:41 +0200, Torvald Riegel wrote:
> > 
> > On Tue, 2017-10-10 at 00:22 +0000, Rodriguez, Sergio SF wrote:
> > > 
> > > 
> > > Thanks, that clarified some doubts I had. In your presentation
> > > where
> > > you mentioned versioning futex word in the 64b futex. Would that
> > > versioning info be set and used solely by user space and opaque
> > > to
> > > kernel?
> > The kernel would use a 64b value as futex word, and userspace would
> > add
> > some kind of "versioning" so that userspace can avoid ABA
> > situations.
> Okay. I was thinking the version info can be outside of the 32b futex
> word handled by the userspace, if not used by kernel.
> 
> > 
> > One could also argue that reaching a 32b overflow and thus ABA
> > would
> > be
> > rare, but that never seemed unlikely enough for me to just ignore
> > it.
> > With 64b, we definitely can ignore it.
> Understood. The 32b overflow on signal count is a concern when we
> don’t
> do quiescence for group switch.
> 
> > 
> > Nonetheless, one could also argue that having to do quiescence is a
> > rare
> > event (32b overflow), and so a (soft) realtime client could perhaps
> > just
> > deal with a rare chance of missing deadlines.  The critical
> > scenario
> > is
> > maybe more likely than actually hitting the ABA.
> > 
> Maybe this can be a 2-step approach, first remove the quiescence with
> version info outside of the 32b futex just for specific real-time
> application to avoid priority inversion with this trade-off or
> limitation on the signal count in 32b futex. 64b futex which requires
> more discussion can be the next step to be added to address the 32b
> overflow.
> 
I did some experiment removing quiescence as I wanted to see the
effect. I also created a test case that can generate priority
inversion. I wanted to see if the priority inversion would happen when
there is no quiescence. I see dis-ordered wake-up when there is no
quiescence. If I understood correctly, the purpose of quiescence is 1)
to make sure waiters in group 1 is empty before re-using the group
memory (by group switch), and 2) to maintain the ordering of group
wake-up. The stronger wake-up ordering implemented by current scheme is
achieved not just by group switch but also along with the quiescence.
We need some kind of information to tell there are still older waiters
that have not consumed the signals and that we should not send a signal
(as the signal would wake a waiter from more recent group before the
older waiters are woken). I have not found a way to achieve this
without quiescence.

Maybe we should explore using priority inheritance on top of current
scheme, instead removing the source of priority inversion as I had
attempted to do. I will look at that next.