This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/6][BZ #11588] pi-condvars: add priority inheritance for pthread_cond_* internal lock
- From: "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- To: Gratian Crisan <gratian dot crisan at ni dot com>
- Cc: libc-alpha at sourceware dot org, Darren Hart <dvhart at linux dot intel dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Scot Salmon <scot dot salmon at ni dot com>, Siddhesh Poyarekar <spoyarek at redhat dot com>, Thomas Gleixner <tglx at linutronix dot de>, Torvald Riegel <triegel at redhat dot com>, Clark Williams <williams at redhat dot com>, gratian at gmail dot com
- Date: Wed, 9 Jul 2014 07:16:49 -0700
- Subject: Re: [PATCH 0/6][BZ #11588] pi-condvars: add priority inheritance for pthread_cond_* internal lock
- Authentication-results: sourceware.org; auth=none
- References: <OF6ABEE614 dot FAE80AD2-ON86257D0E dot 006B38F4-86257D0E dot 0070034A at ni dot com>
- Reply-to: paulmck at linux dot vnet dot ibm dot com
On Mon, Jul 07, 2014 at 03:23:27PM -0500, Gratian Crisan wrote:
> Re-submitting an updated version of the series of patches Darren Hart
> posted
> back in 2010. The basic problem they're addressing is the fact that the
> pthread_cond* calls can cause an unbounded priority inversion, described
> in
> BZ #11588.
>
> It took a while but the copyright assignments should all be sorted out
> now.
> Paul E. McKenny submitted the assignment on behalf of IBM and one was
> signed/submitted by relevant parties at National Instruments and FSF.
That did take some time, didn't it?
OK, please help me out here... Exactly which patches did you need me
to send out to exactly which email addresses?
Thanx, Paul
> Longer description: When using a PTHREAD_PRIO_INHERIT mutex with a
> condvar,
> the pthread_cond* calls can still cause an unbounded priority inversion
> via the
> internal condvar lock. The POSIX specification doesn't provide a mechanism
> to
> specify the protocol of the condvar. A new API,
> pthread_condattr_setprotocol_np() and pthread_condattr_getprotocol_np()
> allow
> the user to create a PTHREAD_PRIO_INHERIT condvar. This uses a
> PTHREAD_PRIO_INHERIT mutex for the internal condvar lock, eliminating the
> potential for hitting an unbounded priority inversion on that lock.
>
> The first patch in the series contains the main changes. The second and
> third
> patch add tests. The fourth patch is a benchmark for various combinations
> of
> pthread_cond_* calls. The fifth patch based on the benchmark results
> removes the
> assembly implementations for x86_64 pthread_cond_* functions since the C
> implementation is equivalent in performance and has PI support. The sixth
> patch
> re-enables PI futex support for ARM kernels >= 3.14.3 which now
> unconditionally
> support it.
>
> Torvald Riegel made us aware of the new POSIX changes related to condvars
> (http://austingroupbugs.net/view.php?id=609) and C++11 clarification
> (http://cplusplus.github.com/LWG/lwg-active.html#2190)
> We believe we can work on these issues in parallel and if they end up
> colliding
> we will fix it.
>
> The changes have been tested so far on dual and quad-core x86_64 machines
> and
> ARM dual-core Cortex A9 (Xilinx Zynq-7000). They solve the priority
> inversion
> problem with condvars.
>
> Thanks,
> Gratian
>