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=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 25017 invoked from network); 31 Mar 2020 15:09:27 -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:09:27 -0000 Received: (qmail 3860 invoked by uid 550); 31 Mar 2020 15:09:25 -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 3842 invoked from network); 31 Mar 2020 15:09:24 -0000 Date: Tue, 31 Mar 2020 11:09:12 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200331150912.GU11469@brightrain.aerifal.cx> References: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Simple question regarding read-write locks precedence 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. Do you have any suggested approaches for making this better? Rich