Files
semi-libc/src/thread
Rich Felker e803829e6b 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.
2013-09-20 02:00:27 -04:00
..
2011-02-12 00:22:29 -05:00
2011-09-18 10:14:37 -04:00
2011-08-14 15:17:36 -04:00
2011-03-04 00:45:59 -05:00
2011-03-04 00:45:59 -05:00
2011-03-04 00:45:59 -05:00
2011-04-17 11:43:03 -04:00