Re: pthread condvars and priority inheritance

[Torvald Riegel <triegel at redhat dot com>]

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.

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.
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.

> I am trying to understand more about it and you can correct me
> I am assuming that how the version info would be used is, that the
> waiter would check the version information from the futex word and
> determine if the signal was intended for it to consume.

Yes, something like that.

> If not, it
> would send an artificial one. Is my understanding correct?
> 
> I found this previous conversion on 64b futex on lkml and am in process
> understanding it.  
> 
> https://groups.google.com/forum/#!topic/linux.kernel/kdZwuuTIL20
> 

I've read that conversation in the past, and have seen Linus' comment
why he thinks it's not necessary.  He seems to think only about
synchronization needs that are similar to mutual exclusion, and
essentially boil down to a simple boolean flag: is the lock acquire, or
isn't it?
But condvars are not like that, as they have to represent an ordering
(ie, only some waiters are eligible to consume signals, so there is more
information that must not get lost).

64b futexes could also help in cases where userspace wants to
synchronize through futex words that are full pointers on 64b systems.

If I had to design new futex operations, I'd probably start at 64b (or
at least machine word size on the respective arch, so at least
pointer-type-sized) and think about adding operations that (1) can cover
a wider range of conditions (eg, less-than vs. just equality of futex
word to expected value) and (2) perhaps operations that atomically
update the futex word (though I'd have to page in my past thoughts on
that to remember what precisely I saw a need for, and why).

Have you talked to Thomas Gleixner yet?