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 Fri, 2017-10-06 at 11:42 +0200, Torvald Riegel wrote:
> On Fri, 2017-10-06 at 00:26 +0000, Rodriguez, Sergio SF wrote:
> > 
> > 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/sc
> > > hedu
> > > 
> > > le
> > > 
> > > https://www.youtube.com/playlist?list=PLbzoR-pLrL6oauKOYMdNjN9RuT
> > > SmC6
> > > 
> > > 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? 
> That's not quite the full story.  The 64b futex would avoid the need
> for
> ABA, and thus quiescence.  The waiter groups would still be necessary
> to
> get the normal ordering requirements satisfied (ie, which waiter is
> eligible to consume a signal); the groups could potentially be
> avoided
> if the futex would provide stronger (and suitable) guarantees
> regarding
> which threads are woken up. 

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


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