[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141116232337.GZ22465@brightrain.aerifal.cx>
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.
