Re: [musl] Simple question regarding read-write locks precedence

[Koen Vandeputte <koen.vandeputte@ncentric.com>]

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