Kernelspace C11 atomics for MIPS

[mdf at FreeBSD.org]

On Tue, Jun 4, 2013 at 6:56 AM, John Baldwin <jhb at freebsd.org> wrote:

> On Tuesday, June 04, 2013 9:12:36 am mdf at freebsd.org wrote:
> > <digression>Personally, I find both the C11 atomics and FreeBSD's
> annoying,
> > since "acquire" and "release" semantics are basically an x86 ism.  PPC
> has
> > no notion of this; it has sync and isync and lwsync instructions which
> are
> > separate from the atomic set, but can be combined to create the same
> > effect.  Except the PPC manual is exceptionally explicit about what
> > guarantees sync provides; it gives a mathematical ordering on
> loads/stores
> > i, j and which effects can be seen when.  "Acquire" and "Release" seem to
> > be named because you kinda need one to acquire a lock and kinda need one
> to
> > release it.  But the effect of ordering loads or stores or both doesn't
> > need to be dependent on the store/load, so putting the two together is
> just
> > an x86 convenience (and an annoyance on at least PPC).</digression>
>
> Actually, it came from ia64 (at least for FreeBSD's), not x86. :)  However,
> it is still useful to think about, and they are barriers with respect to
> the
> load/store of the lock cookie.  The requirement that the "acquire" blocks
> any
> subsequent loads/stores in program order from occurring until after the
> operation on the lock cookie succeeds and that "release" prevents any
> loads/stores frmo moving past the operation on the lock cookie is not quite
> the same as a traditional read or write barrier.  acquire and release only
> require a barrier in one direction and enforce ordering on both reads and
> writes.


Yeah, thinking more I feel sorry for those CISC architectures that need so
many C primitives because it's less efficient to emit a memory fence then
the load (or fence then store).  It is less elegant, though, and the C
standard had to add all the fenced variants of atomics to support it.

Thanks,
matthew