This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is this pthread_cond_wait() race possible
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? 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.
Sebastian