fluencelabs/musl
1
0
Fork 0
mirror of https://github.com/fluencelabs/musl synced 2025-05-03 11:02:14 +00:00
Code Issues Projects Releases Wiki Activity
musl/src/thread/pthread_cond_timedwait.c

58 lines
1.3 KiB
C
Raw Normal View History

initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
#include "pthread_impl.h"
fix deadlock in condition wait whenever there are multiple waiters it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
2011-09-22 21:08:55 -04:00
struct cm {
pthread_cond_t *c;
pthread_mutex_t *m;
};
new futex-requeue-based pthread_cond_broadcast implementation this avoids the "stampede effect" where pthread_cond_broadcast would result in all waiters waking up simultaneously, only to immediately contend for the mutex and go back to sleep.
2011-09-25 02:38:03 -04:00
static void unwait(pthread_cond_t *c, pthread_mutex_t *m)
{
int w;
/* Cannot leave waiting status if there are any live broadcasters
* which might be inspecting/using the mutex. */
while ((w=c->_c_bcast)) __wait(&c->_c_bcast, &c->_c_leavers, w, 0);
/* If the waiter count is zero, it must be the case that the
* caller's count has been moved to the mutex due to bcast. */
do w = c->_c_waiters;
while (w && a_cas(&c->_c_waiters, w, w-1)!=w);
if (!w) a_dec(&m->_m_waiters);
}
fix deadlock in condition wait whenever there are multiple waiters it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
2011-09-22 21:08:55 -04:00
static void cleanup(void *p)
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
{
fix deadlock in condition wait whenever there are multiple waiters it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
2011-09-22 21:08:55 -04:00
struct cm *cm = p;
new futex-requeue-based pthread_cond_broadcast implementation this avoids the "stampede effect" where pthread_cond_broadcast would result in all waiters waking up simultaneously, only to immediately contend for the mutex and go back to sleep.
2011-09-25 02:38:03 -04:00
unwait(cm->c, cm->m);
fix deadlock in condition wait whenever there are multiple waiters it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
2011-09-22 21:08:55 -04:00
pthread_mutex_lock(cm->m);
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
}
int pthread_cond_timedwait(pthread_cond_t *c, pthread_mutex_t *m, const struct timespec *ts)
{
fix deadlock in condition wait whenever there are multiple waiters it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
2011-09-22 21:08:55 -04:00
struct cm cm = { .c=c, .m=m };
fix ABA race in cond vars, improve them overall previously, a waiter could miss the 1->0 transition of block if another thread set block to 1 again after the signal function set block to 0. we now use the caller's thread id as a unique token to store in block, which no other thread will ever write there. this ensures that if block still contains the tid, no signal has occurred. spurious wakeups will of course occur whenever there is a spurious return from the futex wait and another thread has begun waiting on the cond var. this should be a rare occurrence except perhaps in the presence of interrupting signal handlers. signal/bcast operations have been improved by noting that they need not avoid inspecting the cond var's memory after changing the futex value. because the standard allows spurious wakeups, there is no way for an application to distinguish between a spurious wakeup just before another thread called signal/bcast, and the deliberate wakeup resulting from the signal/bcast call. thus the woken thread must assume that the signalling thread may still be waiting to act on the cond var, and therefore it cannot destroy/unmap the cond var.
2011-09-23 22:58:45 -04:00
int r, e, tid;
overhaul pthread cancellation 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-17 11:43:03 -04:00
unify and overhaul timed futex waits 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-02 21:11:36 -04:00
if (ts && ts->tv_nsec >= 1000000000UL)
return EINVAL;
overhaul pthread cancellation 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-17 11:43:03 -04:00
pthread_testcancel();
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
new futex-requeue-based pthread_cond_broadcast implementation this avoids the "stampede effect" where pthread_cond_broadcast would result in all waiters waking up simultaneously, only to immediately contend for the mutex and go back to sleep.
2011-09-25 02:38:03 -04:00
if (c->_c_mutex != (void *)-1) c->_c_mutex = m;
fix ABA race in cond vars, improve them overall previously, a waiter could miss the 1->0 transition of block if another thread set block to 1 again after the signal function set block to 0. we now use the caller's thread id as a unique token to store in block, which no other thread will ever write there. this ensures that if block still contains the tid, no signal has occurred. spurious wakeups will of course occur whenever there is a spurious return from the futex wait and another thread has begun waiting on the cond var. this should be a rare occurrence except perhaps in the presence of interrupting signal handlers. signal/bcast operations have been improved by noting that they need not avoid inspecting the cond var's memory after changing the futex value. because the standard allows spurious wakeups, there is no way for an application to distinguish between a spurious wakeup just before another thread called signal/bcast, and the deliberate wakeup resulting from the signal/bcast call. thus the woken thread must assume that the signalling thread may still be waiting to act on the cond var, and therefore it cannot destroy/unmap the cond var.
2011-09-23 22:58:45 -04:00
a_inc(&c->_c_waiters);
c->_c_block = tid = pthread_self()->tid;
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
if ((r=pthread_mutex_unlock(m))) return r;
fix ABA race in cond vars, improve them overall previously, a waiter could miss the 1->0 transition of block if another thread set block to 1 again after the signal function set block to 0. we now use the caller's thread id as a unique token to store in block, which no other thread will ever write there. this ensures that if block still contains the tid, no signal has occurred. spurious wakeups will of course occur whenever there is a spurious return from the futex wait and another thread has begun waiting on the cond var. this should be a rare occurrence except perhaps in the presence of interrupting signal handlers. signal/bcast operations have been improved by noting that they need not avoid inspecting the cond var's memory after changing the futex value. because the standard allows spurious wakeups, there is no way for an application to distinguish between a spurious wakeup just before another thread called signal/bcast, and the deliberate wakeup resulting from the signal/bcast call. thus the woken thread must assume that the signalling thread may still be waiting to act on the cond var, and therefore it cannot destroy/unmap the cond var.
2011-09-23 22:58:45 -04:00
do e = __timedwait(&c->_c_block, tid, c->_c_clock, ts, cleanup, &cm, 0);
while (c->_c_block == tid && (!e || e==EINTR));
if (e == EINTR) e = 0;
new futex-requeue-based pthread_cond_broadcast implementation this avoids the "stampede effect" where pthread_cond_broadcast would result in all waiters waking up simultaneously, only to immediately contend for the mutex and go back to sleep.
2011-09-25 02:38:03 -04:00
unwait(c, m);
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
if ((r=pthread_mutex_lock(m))) return r;
overhaul pthread cancellation 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-17 11:43:03 -04:00
pthread_testcancel();
initial check-in, version 0.5.0
2011-02-12 00:22:29 -05:00
return e;
}
Reference in New Issue Copy Permalink