Re:QWaitCondition: Solving the Unavoidable Race (2014)
by gpderetta on Thursday February 18, 2021 @09:48AM
(#26180380)
A few years ago I strongly defended this very point on here HN. As far as I knew, you only need to signal while owning the lock if you want to rely on the stronger guarantees of realtime scheduling.
Since then I stumbled upon another scenario were you need to hold the lock for correctness: a producer calls pthread_cond_signal which wakes up a waiter that then destroys the condition variable. This would get flagged by tsan and often cause segfaults especially when the memory is freed. It was not obvious from the docs that this is not allowed, but as apparently pthread_cond_signal can still inspect the condition variable states after waking a waiter.
My use case was fairly simple (I was implementing an event count), so I reimplemented it on top of a raw futex and made sure that signal would return straight away, but signaling while holding the mutex and only destroying the condvar after releasing the mutex would have also fixed it.
Since then I stumbled upon another scenario were you need to hold the lock for correctness: a producer calls pthread_cond_signal which wakes up a waiter that then destroys the condition variable. This would get flagged by tsan and often cause segfaults especially when the memory is freed. It was not obvious from the docs that this is not allowed, but as apparently pthread_cond_signal can still inspect the condition variable states after waking a waiter.
My use case was fairly simple (I was implementing an event count), so I reimplemented it on top of a raw futex and made sure that signal would return straight away, but signaling while holding the mutex and only destroying the condvar after releasing the mutex would have also fixed it.