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 27023 invoked from network); 31 Mar 2020 15:27:00 -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:27:00 -0000 Received: (qmail 13474 invoked by uid 550); 31 Mar 2020 15:26:59 -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 13456 invoked from network); 31 Mar 2020 15:26:58 -0000 Date: Tue, 31 Mar 2020 11:26:46 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200331152646.GV11469@brightrain.aerifal.cx> References: <5a0db239-4121-8a70-832a-e43ce7632d8e@ncentric.com> <20200331150912.GU11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:21:06PM +0200, Koen Vandeputte wrote: > > 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 Thanks. While I specifically did not implement (or define a macro for) PTHREAD_RWLOCK_PREFER_WRITER_NP because it's misleading to advertise support for it when it fundamentally can't work, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP seems like a viable extension to support. Anyone else see potential problems supporting it that I might be missing? Rich