diff options
author | Rich Felker <dalias@aerifal.cx> | 2011-09-23 22:58:45 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2011-09-23 22:58:45 -0400 |
commit | 97c5b5a87c3d9df54278e1073d6177f77536bd32 (patch) | |
tree | f93711dd0ab36697fb5a56d81b4f439a7b8eca68 /src/internal/pthread_impl.h | |
parent | c41a76f58ce0238172effe982f2cee7bbd2a60a4 (diff) | |
download | musl-97c5b5a87c3d9df54278e1073d6177f77536bd32.tar.gz musl-97c5b5a87c3d9df54278e1073d6177f77536bd32.tar.xz musl-97c5b5a87c3d9df54278e1073d6177f77536bd32.zip |
fix ABA race in cond vars, improve them overall
previously, a waiter could miss the 1->0 transition of block if another thread set block to 1 again after the signal function set block to 0. we now use the caller's thread id as a unique token to store in block, which no other thread will ever write there. this ensures that if block still contains the tid, no signal has occurred. spurious wakeups will of course occur whenever there is a spurious return from the futex wait and another thread has begun waiting on the cond var. this should be a rare occurrence except perhaps in the presence of interrupting signal handlers. signal/bcast operations have been improved by noting that they need not avoid inspecting the cond var's memory after changing the futex value. because the standard allows spurious wakeups, there is no way for an application to distinguish between a spurious wakeup just before another thread called signal/bcast, and the deliberate wakeup resulting from the signal/bcast call. thus the woken thread must assume that the signalling thread may still be waiting to act on the cond var, and therefore it cannot destroy/unmap the cond var.
Diffstat (limited to 'src/internal/pthread_impl.h')
0 files changed, 0 insertions, 0 deletions