| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
tests/benchmarks.
|
|
|
|
|
|
with a recursive mutex that was locked by the current thread, the
function was failing with a success return code.
|
|
exit.
|
|
|
|
|
|
|
|
a non-cancelable sem_wait() function. This is consistent with the
way that pthread_mutex_timedlock.c does it.
(pthread_mutex_lock): Use ptw32_semwait() instead of sem_wait().
|
|
* pthread_mutex_trylock.c: Should return EBUSY rather than EDEADLK.
* pthread_mutex_destroy.c: Remove redundant ownership test (the
trylock call does this for us); do not destroy a recursively locked
mutex.
|
|
* pthread_cond_destroy.c (pthread_cond_destroy):
When two different threads exist, and one is attempting to
destroy a condition variable while the other is attempting to
initialize a condition variable that was created with
PTHREAD_COND_INITIALIZER, a deadlock can occur. Shrink
the ptw32_cond_list_lock critical section to fix it.
|
|
|
|
Remove code designed to avoid/prevent spurious wakeup
problems. It is believed that the sem_timedwait() call
is consuming a CV signal that it shouldn't and this is
breaking the avoidance logic.
|
