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