Re: Test-lock hang (not 100% reproducible) on GNU/Linux

[Torvald Riegel]

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).