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
