Re: read-write locks

[Torvald Riegel]

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