diff options
author | Rich Felker <dalias@aerifal.cx> | 2020-10-30 11:21:06 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2020-10-30 11:21:06 -0400 |
commit | 27b2fc9d6db956359727a66c262f1e69995660aa (patch) | |
tree | 457269a4769dbf8873bd3479fbbbeb5b9f03539f /src/stdio/rename.c | |
parent | 7c71792e87691451f2a6b76348e83ad1889f1dcb (diff) | |
download | musl-27b2fc9d6db956359727a66c262f1e69995660aa.tar.gz musl-27b2fc9d6db956359727a66c262f1e69995660aa.tar.bz2 musl-27b2fc9d6db956359727a66c262f1e69995660aa.tar.xz musl-27b2fc9d6db956359727a66c262f1e69995660aa.zip |
fix missing-wake regression in pthread_cond_wait
the reasoning in commit 2d0bbe6c788938d1332609c014eeebc1dff966ac was
not entirely correct. while it's true that setting the waiters flag
ensures that the next unlock will perform a wake, it's possible that
the wake is consumed by a mutex waiter that has no relationship with
the condvar wait queue being processed, which then takes the mutex.
when that thread subsequently unlocks, it sees no waiters, and leaves
the rest of the condvar queue stuck.
bring back the waiter count adjustment, but skip it for PI mutexes,
for which a successful lock-after-waiting always sets the waiters bit.
if future changes are made to bring this same waiters-bit contract to
all lock types, this can be reverted.
Diffstat (limited to 'src/stdio/rename.c')
0 files changed, 0 insertions, 0 deletions