Date: Sun, 16 Nov 2014 18:23:37 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: ARM atomics overhaul for musl 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.