From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5943 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 2/2] avoid taking _c_lock if we know it isn't necessary Date: Wed, 27 Aug 2014 16:07:56 -0400 Message-ID: <20140827200756.GS12888@brightrain.aerifal.cx> References: <1409133335.4476.30.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409170096 11216 80.91.229.3 (27 Aug 2014 20:08:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 20:08:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5950-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 27 22:08:11 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XMjVr-00061w-Bi for gllmg-musl@plane.gmane.org; Wed, 27 Aug 2014 22:08:11 +0200 Original-Received: (qmail 26342 invoked by uid 550); 27 Aug 2014 20:08:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26328 invoked from network); 27 Aug 2014 20:08:09 -0000 Content-Disposition: inline In-Reply-To: <1409133335.4476.30.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5943 Archived-At: On Wed, Aug 27, 2014 at 11:57:47AM +0200, Jens Gustedt wrote: > + /* Since this leaving waiter might not have held the _c_lock, the following */ > + /* __wake might be issued when the signaler is still inside its CS. */ > + /* But if so, this avoids a __wait of the signaler, which more important. */ > + /* This should not target any spurious wake up in any other thread: */ > + /* ref is on the stack of the signaler, and that signaler is still alive. */ > if (ref) { > if (a_fetch_add(ref, -1)==1) > __wake(ref, 1, 1); Can't you avoid that with the design I suggested, having the signaler use an extra ref count on itself, which it decrements right before waiting? Aside from that, based on my reading so far, these patches look like they should work correctly. But since we both want to get C11 threads done, let's put them aside for now (pending some testing for measurable benefits). I also have some other potential changes to this code based on my latest comments to: http://austingroupbugs.net/view.php?id=609 regarding things they seem to deem as requirements, and which musl does not satisfy, that are specified in non-normative text. So there's likely to be more cond var work to do before the release still... Rich