summaryrefslogtreecommitdiff
path: root/src/thread/sem_timedwait.c
AgeCommit message (Collapse)AuthorLines
2011-08-02fix sem_timedwait bug introduced in timedwait unificationRich Felker-0/+1
this dec used to be performed by the cancellation handler, which was called when popped.
2011-08-02unify and overhaul timed futex waitsRich Felker-7/+1
new features: - FUTEX_WAIT_BITSET op will be used for timed waits if available. this saves a call to clock_gettime. - error checking for the timespec struct is now inside __timedwait so it doesn't need to be duplicated everywhere. cond_timedwait still needs to duplicate it to avoid unlocking the mutex, though. - pushing and popping the cancellation handler is delegated to __timedwait, and cancellable/non-cancellable waits are unified.
2011-08-02overhaul posix semaphores to fix destructability raceRich Felker-23/+13
the race condition these changes address is described in glibc bug report number 12674: http://sourceware.org/bugzilla/show_bug.cgi?id=12674 up until now, musl has shared the bug, and i had not been able to figure out how to eliminate it. in short, the problem is that it's not valid for sem_post to inspect the waiters count after incrementing the semaphore value, because another thread may have already successfully returned from sem_wait, (rightly) deemed itself the only remaining user of the semaphore, and chosen to destroy and free it (or unmap the shared memory it's stored in). POSIX is not explicit in blessing this usage, but it gives a very explicit analogous example with mutexes (which, in musl and glibc, also suffer from the same race condition bug) in the rationale for pthread_mutex_destroy. the new semaphore implementation augments the waiter count with a redundant waiter indication in the semaphore value itself, representing the presence of "last minute" waiters that may have arrived after sem_post read the waiter count. this allows sem_post to read the waiter count prior to incrementing the semaphore value, rather than after incrementing it, so as to avoid accessing the semaphore memory whatsoever after the increment takes place. a similar, but much simpler, fix should be possible for mutexes and other locking primitives whose usage rules are stricter than semaphores.
2011-04-17overhaul pthread cancellationRich Felker-4/+1
this patch improves the correctness, simplicity, and size of cancellation-related code. modulo any small errors, it should now be completely conformant, safe, and resource-leak free. the notion of entering and exiting cancellation-point context has been completely eliminated and replaced with alternative syscall assembly code for cancellable syscalls. the assembly is responsible for setting up execution context information (stack pointer and address of the syscall instruction) which the cancellation signal handler can use to determine whether the interrupted code was in a cancellable state. these changes eliminate race conditions in the previous generation of cancellation handling code (whereby a cancellation request received just prior to the syscall would not be processed, leaving the syscall to block, potentially indefinitely), and remedy an issue where non-cancellable syscalls made from signal handlers became cancellable if the signal handler interrupted a cancellation point. x86_64 asm is untested and may need a second try to get it right.
2011-04-06major semaphore improvements (performance and correctness)Rich Felker-15/+30
1. make sem_[timed]wait interruptible by signals, per POSIX 2. keep a waiter count in order to avoid unnecessary futex wake syscalls
2011-03-24overhaul cancellation to fix resource leaks and dangerous behavior with signalsRich Felker-1/+4
this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit...
2011-03-10fix some semaphore wait semantics (race condition deadlock and error checking)Rich Felker-0/+5
2011-03-07fix off-by-one error in sem_(timed)wait (using old sem value instead of new)Rich Felker-1/+1
2011-03-04implement POSIX semaphoresRich Felker-0/+18