fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-06-25 12:42:02 +00:00
Code Issues Projects Releases Wiki Activity

fix potential deadlock bug in libc-internal locking logic

Browse Source 
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.
This commit is contained in:
Rich Felker
2013-09-20 02:00:27 -04:00
parent d8e283df58
commit e803829e6b
3 changed files with 15 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/internal/libc.h
View File

@ -53,8 +53,8 @@ void __lock(volatile int *) ATTR_LIBC_VISIBILITY;
void __unlock(volatile int *) ATTR_LIBC_VISIBILITY;
int __lockfile(FILE *) ATTR_LIBC_VISIBILITY;
void __unlockfile(FILE *) ATTR_LIBC_VISIBILITY;
#define LOCK(x) (libc.threads_minus_1 ? (__lock(x),1) : ((void)(x),1))
#define UNLOCK(x) (libc.threads_minus_1 ? (__unlock(x),1) : ((void)(x),1))
#define LOCK(x) __lock(x)
#define UNLOCK(x) __unlock(x)
void __synccall(void (*)(void *), void *);
int __setxid(int, int, int, int);