svn commit: r251782 - head/sys/sparc64/sparc64

[Ed Schouten]

Hi Marius,

2013/6/15 Marius Strobl <marius at alchemy.franken.de>:
> Semantically, this change is wrong; what we really need here is an
> acquire variant. Using the release variant instead happens to also
> work - albeit additionally wastes CPU cycles for the write memory
> barrier - because in total store order, atomic operations implicitly
> include the read memory barrier necessary for acquire semantics. In
> other words, atomic(9) is in dare need of atomic_store_acq_<type>().

I personally dislike the idea of extending the existing atomic(9) API.
My long-term goal would be that we could just use C11 atomics instead
of using our own home-grown API. If we can't express this using the
atomic(9) API, I'd just like us to use <stdatomic.h> instead.

Reading up on the C11 standard (section 5.1.2.4), it seems that the
abstract model of threads described does not allow stores to be a
acquire operations. This does make sense, though. A load can of course
not be a release operation. Because releases synchronize with
acquires, a store being an acquire operation would have nothing to
synchronize with.

So I guess in this case we should solve it by using a relaxed store,
followed by an acquire fence:

http://80386.nl/pub/sparc64-atomic.txt

Would that work for you?

--
Ed Schouten <ed at 80386.nl>