History log of /seL4-refos-master/libs/libmuslc/src/thread/sem_trywait.c
Revision Date Author Comments
# 07e62953 23-Jul-2012 Rich Felker <dalias@aerifal.cx>

retry on cas failures in sem_trywait

this seems counter-intuitive since sem_trywait is supposed to just try
once, not wait for the semaphore. however, the retry loop is not a
wait. instead, it's to handle the case where the value changes due to
a simultaneous post or wait from another thread while the semaphore
value remains positive. in such a case, it's absolutely wrong for
sem_trywait to fail with EAGAIN because the semaphore is not busy.


# 88c4e720 02-Aug-2011 Rich Felker <dalias@aerifal.cx>

overhaul posix semaphores to fix destructability race

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.


# e983aea0 14-Apr-2011 Rich Felker <dalias@aerifal.cx>

change sem_trywait algorithm so it never has to call __wake


# a113434c 05-Apr-2011 Rich Felker <dalias@aerifal.cx>

major semaphore improvements (performance and correctness)

1. make sem_[timed]wait interruptible by signals, per POSIX
2. keep a waiter count in order to avoid unnecessary futex wake syscalls


# cfe581b6 10-Mar-2011 Rich Felker <dalias@aerifal.cx>

fix some semaphore wait semantics (race condition deadlock and error checking)


# 6fc5fdbd 03-Mar-2011 Rich Felker <dalias@aerifal.cx>

implement POSIX semaphores