[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: read-write locks
From: |
Bruno Haible |
Subject: |
Re: read-write locks |
Date: |
Fri, 06 Jan 2017 15:25:44 +0100 |
User-agent: |
KMail/4.8.5 (Linux/3.8.0-44-generic; KDE/4.8.5; x86_64; ; ) |
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
- Re: bugs in gnulib thread modules, (continued)
- Re: read-write locks, Bruno Haible, 2017/01/05
- Re: read-write locks, Torvald Riegel, 2017/01/06
- Re: read-write locks,
Bruno Haible <=
- Re: read-write locks, Torvald Riegel, 2017/01/06
- Re: read-write locks, throttling, Bruno Haible, 2017/01/06
- Re: read-write locks, throttling, Torvald Riegel, 2017/01/06
- Re: read-write locks, Kamil Dudka, 2017/01/05
- Re: read-write locks, Torvald Riegel, 2017/01/06
- Re: read-write locks, Bruno Haible, 2017/01/06
- Re: read-write locks, Torvald Riegel, 2017/01/06