diff options
author | Rich Felker <dalias@aerifal.cx> | 2020-10-26 15:56:25 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2020-10-26 15:56:25 -0400 |
commit | 2d0bbe6c788938d1332609c014eeebc1dff966ac (patch) | |
tree | 6c673d0c6d5bb2dce4fbb9cb216101a482dc472f /src/fcntl | |
parent | 0b87551bdfb74ac411caa335d8ad0b89a7f139c6 (diff) | |
download | musl-2d0bbe6c788938d1332609c014eeebc1dff966ac.tar.gz musl-2d0bbe6c788938d1332609c014eeebc1dff966ac.tar.xz musl-2d0bbe6c788938d1332609c014eeebc1dff966ac.zip |
fix pthread_cond_wait paired with with priority-inheritance mutex
pthread_cond_wait arranged for requeued waiters to wake when the mutex is unlocked by temporarily adjusting the mutex's waiter count. commit 54ca677983d47529bab8752315ac1a2b49888870 broke this when introducing PI mutexes by repurposing the waiter count field of the mutex structure. since then, for PI mutexes, the waiter count adjustment was misinterpreted by the mutex locking code as indicating that the mutex is non a non-recoverable state. it would be possible to special-case PI mutexes here, but instead just drop all adjustment of the waiters count, and instead use the lock word waiters bit for all mutex types. since the mutex is either held by the caller or in unrecoverable state at the time the bit is set, it will necessarily still be set at the time of any subsequent valid unlock operation, and this will produce the desired effect of waking the next waiter. if waiter counts are entirely dropped at some point in the future this code should still work without modification.
Diffstat (limited to 'src/fcntl')
0 files changed, 0 insertions, 0 deletions