On Thu, 2017-01-05 at 22:20 +0100, Kamil Dudka wrote: > On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote: > > Torvald Riegel wrote: > > > 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). > > > > Some background about the thinking and methodology that drives gnulib: > > > > * Gnulib tries to makes POSIX (and other) APIs usable in an easy way. > > We work around not only outright bugs, but also usability problems > > that get in the way, such as: > > * gnulib overrides the printf() function if this function crashes on > > random data (the crash would be standards compliant, some people say, > > but the data can be read from external files and we don't want our > > programs to crash). > > * gnulib overrides the fmal() function if it produces mathematically > > incorrect values. > > * gnulib overrides the iconv_open() function so that it will never report > > that it cannot convert from "ISO-8859-1" to "UTF-8". > > * gnulib overrides the re_search() function so that it understands > > the most important parts of GNU regex syntax. > > > > * Gnulib favours reliability over efficiency. For example: > > * "cp --help > /dev/full" fails with an error message. Thanks to gnulib. > > * Its date parser prints warnings when there are ambiguities. > > * It makes it easy to check all memory allocations (module 'xalloc'), > > all size_t computations (module 'xsize'), and to not overlook failures > > of POSIX function such as freopen, getcwd, readlink, setenv, strtol, > > vasprintf etc. > > > > If it costs an allocation of a couple of memory words, or a couple of > > extra instruction, to achieve these goals, we just don't care. > > Unfortunately, it is not the only cost. Please take into consideration also > the manpower spent on debugging random build hangs in each single GNU project > that happened to pull in gnulib's lock module. When you run tests in > parallel > and have no direct access to build machines, it is not even obvious which of > the tests hangs. Additionally, I guess that most of the projects whose > builds > hanged for no apparent reason do not care about rwlocks at all.
What are the rwlock users, actually? A web search for gl_rwlock_t seems to only turn up lock.h, but no users (unlike gl_lock_t, for example). > > We want a lock facility that can EASILY achieve > > - no writer starvation, and > > - no reader starvation. > > Which gnulib-based projects have the above requirements (besides the test)? I'd second that (as a follow-up to my previous question).
