about summary refs log tree commit diff
path: root/src/thread/pthread_detach.c
Commit message (Collapse)AuthorAgeFilesLines
* improve joinable/detached thread state handlingRich Felker2018-05-051-4/+3
| | | | | | | | | | | | | | | | | previously, some accesses to the detached state (from pthread_join and pthread_getattr_np) were unsynchronized; they were harmless in programs with well-defined behavior, but ugly. other accesses (in pthread_exit and pthread_detach) were synchronized by a poorly named "exitlock", with an ad-hoc trylock operation on it open-coded in pthread_detach, whose only purpose was establishing protocol for which thread is responsible for deallocation of detached-thread resources. instead, use an atomic detach_state and unify it with the futex used to wait for thread exit. this eliminates 2 members from the pthread structure, gets rid of the hackish lock usage, and makes rigorous the trap added in commit 80bf5952551c002cf12d96deb145629765272db0 for catching attempts to join detached threads. it should also make attempt to detach an already-detached thread reliably trap.
* consistently use the LOCK an UNLOCK macrosJens Gustedt2018-01-091-1/+1
| | | | | | | 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.
* new lock algorithm with state and congestion count in one atomic intJens Gustedt2018-01-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* fix read-after-free type error in pthread_detachRich Felker2017-10-131-1/+2
| | | | | | | | | | | 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.
* add C11 thread creation and related thread functionsRich Felker2014-09-071-1/+3
| | | | | | | | | | | | | | | | | based on patch by Jens Gustedt. the main difficulty here is handling the difference between start function signatures and thread return types for C11 threads versus POSIX threads. pointers to void are assumed to be able to represent faithfully all values of int. the function pointer for the thread start function is cast to an incorrect type for passing through pthread_create, but is cast back to its correct type before calling so that the behavior of the call is well-defined. changes to the existing threads implementation were kept minimal to reduce the risk of regressions, and duplication of code that carries implementation-specific assumptions was avoided for ease and safety of future maintenance.
* use weak symbols for the POSIX functions that will be used by C threadsJens Gustedt2014-09-061-2/+6
| | | | | | | | | | The intent of this is to avoid name space pollution of the C threads implementation. This has two sides to it. First we have to provide symbols that wouldn't pollute the name space for the C threads implementation. Second we have to clean up some internal uses of POSIX functions such that they don't implicitly drag in such symbols.
* fix several locks that weren't updated right for new futex-based __lockRich Felker2012-07-121-2/+2
| | | | | | these could have caused memory corruption due to invalid accesses to the next field. all should be fixed now; I found the errors with fgrep -r '__lock(&', which is bogus since the argument should be an array.
* fix potential race condition in detached threadsRich Felker2012-07-111-2/+2
| | | | | | | after the thread unmaps its own stack/thread structure, the kernel, performing child tid clear and futex wake, could clobber a new mapping made at the same location as the just-removed thread's tid field. disable kernel clearing of child tid to prevent this.
* fix more instances of old a_xchg (use new a_swap name)Rich Felker2011-09-161-1/+1
|
* initial check-in, version 0.5.0 v0.5.0Rich Felker2011-02-121-0/+11