[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d31ecb32-704d-ecc5-a4a6-b80c7b8ad98e@ncentric.com>
Date: Tue, 31 Mar 2020 17:21:06 +0200
From: Koen Vandeputte <koen.vandeputte@...ntric.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>
Subject: Re: Simple question regarding read-write locks precedence
On 31.03.20 17:09, Rich Felker wrote:
> On Tue, Mar 31, 2020 at 05:05:27PM +0200, Koen Vandeputte wrote:
>> Hi All,
>>
>> I've written a user app which make use of reader-writer locks.
>>
>> Topology is pretty simple:
>>
>> - 1 writer
>>
>> - 4 readers
>>
>>
>> Writes only occur once in a while.
>>
>> Readers are heavy users of the lock.
>>
>>
>> The default behavior in musl is Reader precedence.
>>
>> In my usecase, it means that a writer never aquires the lock causing
>> writer starvation.
>>
>> Debugging nicely shows that readers also "jump over" the waiting
>> writer as there is always at least 1 reader present in the critical
>> section at any time.
>>
>> Going through the source code shows that there is no support for
>> specifying lock attributes which give writers precedence over
>> readers.
>>
>>
>> Is there an update scheduled to add the required attribute types
>> which allow writer precedence to avoid starvation?
> The POSIX model of allowing recursive read locks fundamentally doesn't
> admit writer preference -- there's no way to distinguish the case of
> new reader vs an additional recursive lock by an existing reader
> without O(n) space. If you disallow the latter (recursive locks while
> a writer is waiting) you get deadlocks all over the place in intended
> usage model.
Hi Rich,
Thanks for the very fast reply.
I've red about the trivial deadlocks, but isn't this the reason why
*PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP* exists?
It's the user's responsibility to avoid recursive reading here .. but at
least it allows preferred writes.
See description in:
http://man7.org/linux/man-pages/man3/pthread_rwlockattr_setkind_np.3.html
>
> Do you have any suggested approaches for making this better?
I'll definitely take a look at it.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
