Date: Tue, 4 Jun 2013 09:56:00 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: mdf@freebsd.org, Andre Oppermann <andre@freebsd.org>, freebsd-mips@freebsd.org, Ed Schouten <ed@80386.nl> Subject: Re: Kernelspace C11 atomics for MIPS Message-ID: <201306040956.01065.jhb@freebsd.org> In-Reply-To: <CAMBSHm8B01GRgqKtdTF1wcktPNVOsibqUuiUVJhsiN4m6-CaXQ@mail.gmail.com> References: <CAJOYFBD502MYbkVR2hnVDTYWOvOUr15=OPyjotNvv%2BZ09vQ1OQ@mail.gmail.com> <51ADA308.6040904@freebsd.org> <CAMBSHm8B01GRgqKtdTF1wcktPNVOsibqUuiUVJhsiN4m6-CaXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, June 04, 2013 9:12:36 am mdf@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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306040956.01065.jhb>