Re: read-write locks

[Bruno Haible]

Torvald Riegel wrote:
> > The rwlock writer starvation problem is not solved by throttling to a fixed
> > percentage of CPU time: If every reader thread spends 10% of its time with 
> > the
> > rwlock held, it will work fine with 4 CPUs, but it will hang with 24 CPUs.
> 
> Well, obviously, you need to throttle in such a way that all work can be
> performed eventually before new work arrives.  For example, don't accept
> new work for a while if old work hasn't been done yet.

You suggest to implement throttling, but in order to make it work reliably,
you have to implement a system of dynamic control (of multiple parameters)
around it. Such systems are *very hard* to build. Just two examples:
  - It took a long long time until the OOM killer in Linux could reliably
    prevent fork bombs from taking down a system.
  - The Mac OS X 10.5 memory management example from my other mail.
I don't want to get into this area, unless absolutely absolutely necessary.

> The examples you
> bring up, such as GC, suggest that you want abstractions at a much
> higher level than explicit threading and locks, as provided by POSIX and
> C11.  However, you previously also said that you want to make POSIX and
> ISO C easier to use, so there's a gap there.

You're probably right here. I am dissatisfied with how hard it is to make
multithreaded software work in a verifiably reliable way. I don't know what
the answer is, i.e. what abstractions will provide this reliability.

> > The suboptimal unit test clearly shows the starvation problem is
> > not solved altogether, when one uses plain POSIX APIs on glibc.
> 
> But that's the point.  You test for a feature that the tool does not
> intend to provide to you.  To exaggerate, that's like testing that
> x86_64 int overflows after 2^32.

Well, the current POSIX ([TPS] clause) and Solaris and Mac OS X all provide at
least half of what I want: namely, writer-preference and therefore avoidance
of writer starvation.

Bruno