Hello
i discovered recently a race condition while playing with threads
and sem_wait/sem_post
sem_wait may fail with errno set EAGAIN which is not valid since
only sem_trywait is able to set that errno code.
this was causing a bug with a later select() and accept() which
failed since accept does not work if errno is set to EAGAIN.
from my point of view the bug is in sem_timedwait.c
if (!sem_trywait(sem)) return 0;
int spins = 100;
while (spins-- && sem->__val[0] <= 0
&& !sem->__val[1]) a_spin();
while (sem_trywait(sem)) {
the fist sem_trywait will fail with -1 and sets EAGAIN. but the
second sem_trywait will not fail and does return 0. the problem
now is that errno is still present and not reset.
this may cause if sem_post is called from a second thread on the
same semaphore.
of course the same bug affects sem_timedwait itself.
so i assume sem_wait is not thread safe which is bad and is not
follow the posix specification
or am i wrong here?
Sebastian