diff options
author | Rich Felker <dalias@aerifal.cx> | 2013-09-20 02:00:27 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2013-09-20 02:00:27 -0400 |
commit | e803829e6b087c0ed91adc11f87185109bc59b31 (patch) | |
tree | ad2fdda58fbba2c542785d9cc8babcd5f7d001ec /src/thread/x86_64 | |
parent | d8e283df58eb8bff1aa2f8a99347e294c7f67cb9 (diff) | |
download | musl-e803829e6b087c0ed91adc11f87185109bc59b31.tar.gz musl-e803829e6b087c0ed91adc11f87185109bc59b31.tar.xz musl-e803829e6b087c0ed91adc11f87185109bc59b31.zip |
fix potential deadlock bug in libc-internal locking logic
if a multithreaded program became non-multithreaded (i.e. all other threads exited) while one thread held an internal lock, the remaining thread would fail to release the lock. the the program then became multithreaded again at a later time, any further attempts to obtain the lock would deadlock permanently. the underlying cause is that the value of libc.threads_minus_1 at unlock time might not match the value at lock time. one solution would be returning a flag to the caller indicating whether the lock was taken and needs to be unlocked, but there is a simpler solution: using the lock itself as such a flag. note that this flag is not needed anyway for correctness; if the lock is not held, the unlock code is harmless. however, the memory synchronization properties associated with a_store are costly on some archs, so it's best to avoid executing the unlock code when it is unnecessary.
Diffstat (limited to 'src/thread/x86_64')
0 files changed, 0 insertions, 0 deletions