musl/src/thread/pthread_rwlock_wrlock.c

#include "pthread_impl.h"

int pthread_rwlock_wrlock(pthread_rwlock_t *rw)
{
	return pthread_rwlock_timedwrlock(rw, 0);
}
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`#include "pthread_impl.h"`

			`int pthread_rwlock_wrlock(pthread_rwlock_t *rw)`
			`{`
overhaul rwlocks to address several issues like mutexes and semaphores, rwlocks suffered from a race condition where the unlock operation could access the lock memory after another thread successfully obtained the lock (and possibly destroyed or unmapped the object). this has been fixed in the same way it was fixed for other lock types. in addition, the previous implementation favored writers over readers. in the absence of other considerations, that is the best behavior for rwlocks, and posix explicitly allows it. however posix also requires read locks to be recursive. if writers are favored, any attempt to obtain a read lock while a writer is waiting for the lock will fail, causing "recursive" read locks to deadlock. this can be avoided by keeping track of which threads already hold read locks, but doing so requires unbounded memory usage, and there must be a fallback case that favors readers in case memory allocation failed. and all of this must be synchronized. the cost, complexity, and risk of errors in getting it right is too great, so we simply favor readers. tracking of the owner of write locks has been removed, as it was not useful for anything. it could allow deadlock detection, but it's not clear to me that returning EDEADLK (which a buggy program is likely to ignore) is better than deadlocking; at least the latter behavior prevents further data corruption. a correct program cannot invoke this situation anyway. the reader count and write lock state, as well as the "last minute" waiter flag have all been combined into a single atomic lock. this means all state transitions for the lock are atomic compare-and-swap operations. this makes establishing correctness much easier and may improve performance. finally, some code duplication has been cleaned up. more is called for, especially the standard __timedwait idiom repeated in all locks. 2011-08-03 10:21:32 -04:00			`return pthread_rwlock_timedwrlock(rw, 0);`
initial check-in, version 0.5.0 2011-02-12 00:22:29 -05:00			`}`