From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 26381 invoked from network); 31 Mar 2020 15:21:23 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 31 Mar 2020 15:21:23 -0000 Received: (qmail 10028 invoked by uid 550); 31 Mar 2020 15:21:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 10007 invoked from network); 31 Mar 2020 15:21:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncentric-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GoJGfURgPy0bjQsZEmOixddEVhlq1kLevQhxblgjdv4=; b=dN5F0B1sX23UYuMK8kz2qS8IgsOHSTHYx8Xb2j1QT6biDwd4jm6IJxKuxWBoqW1GdQ TOFRYBWL4LD4pypgb427uP7gBkv/ENFMQBVjSWVHmu4+Xm+c+8sDOOUgRD9BgytFehra KPncZyKJBOlCuz4HWZL0qQegJYDMRhd+nVm9w5dmytLD2aktydCL55k/vbTnr3Brcn2t 7WeCs/utmOVMwV+g67IJIDmKtY+qeXNRXSRatDLMDG3Ydif7D1TWeinw9lyepwtpq7K6 0QsgVcEQbwPAWWw73PzK1DXD394Y3AbCJiJsgM3sGj3q8DcXNmIaIQrpVpTHDSHV/yqm 8OJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GoJGfURgPy0bjQsZEmOixddEVhlq1kLevQhxblgjdv4=; b=ZCwCjGQOzDYrAMAG5W8Bu/NvwSvOdDDZ+iCn9Bi5d0QLil585l3FBBfN7Da1Py1dJP tbzS5Rs2ynRAaCsg0S2Ifsa65LcniVU+eacup+56MFM8eZNJTAIllEOMmfrRT4YLH4JY tcEQd6aNKU6yj2Fp+PLPkhHIARJl9Xc8x4um70EYF1u9UUy3bGVYYSsXEpJmdSaC8NAD AVxvFr7n2SgSJKdPIdZe9ru25/XpZGDpR5Ig+AW5dqdzfYbVgRO/fN4G4iJgW7qBVwdW +HFm8pQLW327uErmkpl3dIa3BgdTW7FjPQfaa8bf/5s9R6a7zC3mOuXRT2U/pt3WIG9k +6cQ== X-Gm-Message-State: ANhLgQ0yrL6eL0gK6hEVeK6cjaHlQwI9uQRARxdU+5YucBrvq3Hqztve 3BrN+6JQqg7P5py1kCsOp1VSKhyILKg= X-Google-Smtp-Source: ADFU+vv/AvB2zt4UM6iN/RGFjS1z1UunRobfGsN/6BRhU65cII0TlNshwKo/EVLDwLB4Fpr8MqvecQ== X-Received: by 2002:a1c:e109:: with SMTP id y9mr3866572wmg.62.1585668067921; Tue, 31 Mar 2020 08:21:07 -0700 (PDT) To: musl@lists.openwall.com, Rich Felker References: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> <20200331150912.GU11469@brightrain.aerifal.cx> From: Koen Vandeputte Message-ID: Date: Tue, 31 Mar 2020 17:21:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200331150912.GU11469@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [musl] 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