IMO, users of reader-writer locks should treat them as a mutual-exclusion mechanism. That is, a mechanism that just ensures that two critical sections will not execute concurrently (except if both are readers, of course), so at the same time. It is also important to understand what this does not mean, for example any prioritization of threads attempting to acquire a reader-writer lock. Claiming that prefering writers is required for reader-writer locks to be usable is wrong. If a program needs a particular sort of fairness or starvation-freedom, there are several ways to ensure that, and this does not require to be the same mechanism as the mutual exclusion mechanism.
Please also do note that you seem to be getting along fine with exclusive mutexes that are not guaranteed to be fair or starvation-free. If glibc is making a certain decision about semantics, it might be worthwhile to consider (see http://austingroupbugs.net/view.php?id=1111 and https://sourceware.org/bugzilla/show_bug.cgi?id=13701). IMHO, gnulib synchronization primitives should simply move towards the semantics chosen by C++11 and more recent (if you dislike C++ for some reason, just use the C++ semantics applied to C11; C is lacking behind in terms of preciseness of the specification). Of course you can build your own, but that requires expertise and time. I found two bugs just by briefly scanning through the current lib/glthread/lock.c. As a hint, I'll just mention double-checked locking and order of destruction. And skipping destruction is of course not correct in the general case either (unless I'm misreading lib/glthread/cond.c, for example).
