musl/src/thread/sem_post.c

#include <semaphore.h>
#include "pthread_impl.h"

int sem_post(sem_t *sem)
{
	int val, waiters;
	do {
		val = sem->__val[0];
		waiters = sem->__val[1];
		if (val == SEM_VALUE_MAX) {
			errno = EOVERFLOW;
			return -1;
		}
	} while (a_cas(sem->__val, val, val+1+(val<0)) != val);
	if (val<0 || waiters) __wake(sem->__val, 1, 0);
	return 0;
}
implement POSIX semaphores 2011-03-04 00:45:59 -05:00			`#include <semaphore.h>`
			`#include "pthread_impl.h"`

			`int sem_post(sem_t *sem)`
			`{`
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. 2011-08-02 19:19:09 -04:00			`int val, waiters;`
			`do {`
			`val = sem->__val[0];`
			`waiters = sem->__val[1];`
report sem value overflows in sem_post this is not required by the standard, but it's nicer than corrupting the state and rather inexpensive. 2011-10-26 00:28:47 -04:00			`if (val == SEM_VALUE_MAX) {`
			`errno = EOVERFLOW;`
			`return -1;`
			`}`
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. 2011-08-02 19:19:09 -04:00			`} while (a_cas(sem->__val, val, val+1+(val<0)) != val);`
			`if (val<0 \|\| waiters) __wake(sem->__val, 1, 0);`
implement POSIX semaphores 2011-03-04 00:45:59 -05:00			`return 0;`
			`}`