In all cases this is just a change from two volatile int to one.
In some places there has been a direct usage of the functions. Use the macros consistently everywhere, such that it might be easier later on to capture the fast path directly inside the macro and only have the call overhead on the slow path.
A variant of this new lock algorithm has been presented at SAC'16, see
https://hal.inria.fr/hal-01304108. A full version of that paper is
available at https://hal.inria.fr/hal-01236734.
The main motivation of this is to improve on the safety of the basic lock
implementation in musl. This is achieved by squeezing a lock flag and a
congestion count (= threads inside the critical section) into a single
int. Thereby an unlock operation does exactly one memory
transfer (a_fetch_add) and never touches the value again, but still
detects if a waiter has to be woken up.
This is a fix of a use-after-free bug in pthread_detach that had
temporarily been patched. Therefore this patch also reverts
c1e27367a9b26b9baac0f37a12349fc36567c8b6
This is also the only place where internal knowledge of the lock
algorithm is used.
The main price for the improved safety is a little bit larger code.
Under high congestion, the scheduling behavior will be different
compared to the previous algorithm. In that case, a successful
put-to-sleep may appear out of order compared to the arrival in the
critical section.
calling __unlock on t->exitlock is not valid because __unlock reads the waiters count after making the atomic store that could allow pthread_exit to continue and unmap the thread's stack and the object t points to. for now, inline the __unlock logic with an unconditional futex wake operation so that the waiters count is not needed. once __lock/__unlock have been made safe for self-synchronized destruction, we could switch back to using them.
if the parent thread was able to set the new thread's priority before it reached the check for 'startlock', the new thread failed to restore its signal mask and thus ran with all signals blocked. concept for patch by Sergei, who reported the issue; unnecessary changes were removed and comments added since the whole 'startlock' thing is non-idiomatic and confusing. eventually it should be replaced with use of idiomatic synchronization primitives.
passing to pthread_join the id of a thread which is not joinable results in undefined behavior. in principle the check to trap does not necessarily work if pthread_detach was called after thread creation, since no effort is made here to synchronize access to t->detached, but the check is well-defined and harmless for callers which did not invoke UB, and likely to help catch erroneous code that would otherwise mysteriously hang. patch by William Pitcock.
The flag 1<<7 is used in several places for different purposes that are not always easy to distinguish. Mark those usages that correspond to the flag that is used by the kernel for futexes.
when using the sh4a opcodes, the assembler tags the resulting object file as requiring sh4a. the linker then refuses to (static) link it with object files marked as requiring j2, since there is no isa level that includes both sh4a and j2 instructions.
binutils commit bada43421274615d0d5f629a61a60b7daa71bc15 tightened immediate fixup handling in gas in such a way that the final .arch of an object file must be compatible with the fixups used when the instruction was assembled; this in turn broke assembling of atomics.s, at least in thumb mode. it's not clear whether this should be considered a bug in gas, but .object_arch is preferable anyway for our purpose here of controlling the ISA level tag on the object file being produced, and it's the intended directive for use in object files with runtime code selection. research by Szabolcs Nagy confirmed that .object_arch is supported in all relevant versions of binutils and clang's integrated assembler. patch by Reiner Herrmann.