Is this pthread_cond_wait() race possible

[Torvald Riegel]

On Thu, 2017-06-08 at 14:16 +0200, Sebastian Andrzej Siewior wrote:
> On 2017-06-08 11:51:08 [+0200], Torvald Riegel wrote:
> > No, the second iteration of the outer do-while loop will just run the
> > inner while loop; the inner loop doesn't exit until signals is non-zero
> > (or the group is closed or a timeout occurs, but then the CAS isn't
> > executed).
> 
> Okay. The while loop is within the do loop and
> atomic_compare_exchange_weak_acquire() was part of the outer do loop's
> condition. It looked like it was there all by itself…
> Thanks for clearing that up. So based on this, the waiter does no
> locking except for its atomic ops which should not block (or let it loop
> for a long time based on a condition). 
> If that is the case, then it looks good.
> 
> The counterpart (pthread_cond_signal()) uses __condvar_acquire_lock()
> which is a handcrafted lock with atomics and two bits. Do you have an
> integer field left?

No, otherwise I would have avoided the complexity of embedding the lock
bits :)  One could rearrange the bits in some other way to get a full
32b for the PI lock -- but I don't think that's the fundamental problem.

> This seems to be only part that would break PI. That
> is a low priority thread that owns the lock (and is scheduled out) will
> make every subsequent thread end up in futex_wait(). An integer with
> futex_lock_pi() should fix that.

Have you looked at the presentation I gave at Real-Time Summit last
year?  I think the problem we're facing re PI support is more
fundamental than getting a PI lock in there.