From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13639 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: MSB in rwlock? Date: Tue, 22 Jan 2019 19:22:53 -0500 Message-ID: <20190123002253.GT23599@brightrain.aerifal.cx> References: <20190122202847.GB23924@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="56800"; mail-complaints-to="usenet@ciao.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13655-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 23 01:23:10 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by ciao.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gm6Jx-000Ee1-Ba for gllmg-musl@m.gmane.org; Wed, 23 Jan 2019 01:23:09 +0100 Original-Received: (qmail 20291 invoked by uid 550); 23 Jan 2019 00:23:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20270 invoked from network); 23 Jan 2019 00:23:06 -0000 Content-Disposition: inline In-Reply-To: <20190122202847.GB23924@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13639 Archived-At: On Tue, Jan 22, 2019 at 09:28:47PM +0100, Markus Wichmann wrote: > Hi all, > > would someone kindly explain what the highest bit in the rwlock value is > doing? As far as I can see, it is set whenever one of the locking > functions enters a contended case, and cleared when the unlock function > sets the lock to 0 (so when the last reader or the writer unlocks the > rwlock). But at any other point the bit is masked out, AFAICS. So what > is it doing? Or is it just a vestige that can be done away with? In most of the locking primitives, the high bit of the lock word is used as a maybe-has-waiters flag. It looks like it's redundant with the waiters count field, but it's not. If we used *only* this bit, then threads obtaining the lock after contending for it would have to set it to true (since they couldn't know if they were the last waiter), thereby performing a potentially-useless futex wake when they subsequently unlock it. If on the other hand we used only the waiters count, there would be a race condition at unlock time: between the time the waiter count was read and the time the lock word was unlocked, a new waiter could arrive, and go to sleep on the futex without getting woken up. (The unlocking thread cannot check the waiter count *after* unlocking the lock word, since the lock object may no longer exist at that point.) Rich