From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6524 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ARM atomics overhaul for musl Date: Sun, 16 Nov 2014 18:23:37 -0500 Message-ID: <20141116232337.GZ22465@brightrain.aerifal.cx> References: <20141116055656.GA13940@brightrain.aerifal.cx> <1416177195.16479.110.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 1416180240 9119 80.91.229.3 (16 Nov 2014 23:24:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Nov 2014 23:24:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6537-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 17 00:23:52 2014 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 1Xq9Ae-0001ej-4L for gllmg-musl@m.gmane.org; Mon, 17 Nov 2014 00:23:52 +0100 Original-Received: (qmail 22133 invoked by uid 550); 16 Nov 2014 23:23:50 -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 22122 invoked from network); 16 Nov 2014 23:23:49 -0000 Content-Disposition: inline In-Reply-To: <1416177195.16479.110.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:6524 Archived-At: On Sun, Nov 16, 2014 at 11:33:15PM +0100, Jens Gustedt wrote: > Hello, > > Am Sonntag, den 16.11.2014, 00:56 -0500 schrieb Rich Felker: > > One item on the agenda for this release cycle is overhauling the way > > atomics are done on ARM. I'm cc'ing people who have been involved in > > this discussion in the past in case anyone's not on the musl list and > > has opinions about what should be done. > > > > The current situation looks like the following: ... > > I don't know enough about the nasty details of this architecture to be > helpful, I think. But what I'd very much like to have is some sort of > documentation or standards concerning memory ordering for the atomics > that we use internally. At present, the assumptions made about musl's atomic primitives used internally is that they meet the POSIX requirement for synchronizing memory. They are at least acquire+release barriers. Assuming a POSIX memory model that does not have atomic objects and where you can only access memory when simultaneous modification is excluded by synchronizing functions, I think this is equivalent to sequential consistency, but it's not necessarily equivalent when the application can access atomic objects itself. Does this sound correct? > And also about which OS features are > needed/missing to make atomic operations appear stateless (AKA > "lockfree" in C11 terminology). This is purely dependent on having a hardware CAS of the correct size. musl requires int- and long/pointer-sized CAS, and IMO it's impossible to implement POSIX correctly without them (of course they could be emulated by kernel blocking interrupts and shutting down all but one core temporarily). > Since this is the most complicated architecture (or merely family of > architectures) this is probably the best to start such a reflection. The complexities being discussed here are complexities in the instruction set architecture and the kernel's failure to report the particular variant in use in a reasonable way. The memory model is just a pretty standard relaxed-order. Rich