From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8223 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: What's left for 1.1.11 release? Date: Tue, 28 Jul 2015 10:18:03 -0400 Message-ID: <20150728141803.GS16376@brightrain.aerifal.cx> References: <20150728034036.GA25643@brightrain.aerifal.cx> <1438092578.19958.4.camel@inria.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 1438093101 24709 80.91.229.3 (28 Jul 2015 14:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jul 2015 14:18:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8236-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 28 16:18:20 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZK5hy-0003vq-BG for gllmg-musl@m.gmane.org; Tue, 28 Jul 2015 16:18:18 +0200 Original-Received: (qmail 3925 invoked by uid 550); 28 Jul 2015 14:18:16 -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 3895 invoked from network); 28 Jul 2015 14:18:15 -0000 Content-Disposition: inline In-Reply-To: <1438092578.19958.4.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8223 Archived-At: On Tue, Jul 28, 2015 at 04:09:38PM +0200, Jens Gustedt wrote: > Hello, > > Am Montag, den 27.07.2015, 23:40 -0400 schrieb Rich Felker: > > In principle the a_store issue affects all libc-internal __lock/LOCK > > uses, > > so this worries me since I assumed that UNLOCK had release consistency > for the __atomic implementation. It does. The problem is that it lacks acquire consistency, which we need in order to know whether to wake. > > and stdio locks too, but it's only been observed in malloc. > > Since there don't seem to be any performance-relevant uses of a_store > > that don't actually need the proper barrier, I think we have to just > > put an explicit barrier (lock orl $0,(%esp) or mfence) after the store > > and live with the loss of performance. > > How about using a xchg as instruction? This would perhaps "waste" a > register, but that sort of optimization should not be critical in the > vicinity of code that needs memory synchronization, anyhow. How is this better? My intent was to avoid incurring a read on the cache line that's being written and instead achieve the synchronization by poking at a cache line (the stack) that should not be shared. Rich