| 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.
|
|
|
