This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread condvars and priority inheritance


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 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?
> 
No. I have only started the conversion on this thread. The 64b futex
seems to be a good option to address the 32b futex ABA issue. You
brought up a few other potential usages of having 64b futex. If we can
get some comment and feedback from Thomas, that would be good.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]