Re: ARM atomics overhaul for musl

[Rich Felker <dalias@libc.org>]

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