Date: Mon, 12 Jun 2017 00:37:03 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, Jonathan Looney <jonlooney@gmail.com>, John Baldwin <jhb@freebsd.org>, "Jonathan T. Looney" <jtl@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r319720 - head/sys/dev/vt Message-ID: <20170611231933.F767@besplex.bde.org> In-Reply-To: <20170611130159.GR2088@kib.kiev.ua> References: <201706082047.v58KlI51079003@repo.freebsd.org> <7306919.ixyIA96xWQ@ralph.baldwin.cx> <CADrOrmvH9vL6X7yZ2-djDAV92%2Be4W84z21-y2O4RFfxei8oT%2BQ@mail.gmail.com> <20170610091203.GH2088@kib.kiev.ua> <CADrOrmvUwW30ztKjeTa%2BnZ51L%2B4GPxOHo7oDPHE8TA5gTtJHQg@mail.gmail.com> <20170610182039.GL2088@kib.kiev.ua> <20170611150813.B891@besplex.bde.org> <20170611130159.GR2088@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Jun 2017, Konstantin Belousov wrote: > On Sun, Jun 11, 2017 at 07:53:47PM +1000, Bruce Evans wrote: >> On Sat, 10 Jun 2017, Konstantin Belousov wrote: >> >>> On Sat, Jun 10, 2017 at 09:33:48AM -0700, Jonathan Looney wrote: >>>> Hi Konstantin, >>>> >>>> On Sat, Jun 10, 2017 at 2:12 AM, Konstantin Belousov <kostikbel@gmail.com> >>>> wrote: >>>>> No, acquire is only specified for loads, and release for stores. In other >>>>> words, on some hypothetical ll/sc architecture, the atomic_add_acq() >>>>> could be implemented as follows, in asm-pseudocode >>>>> atomic_add_acq(int x): >>>>> ll x, r1 >>>>> acq x >>>>> add 1, r >>>>> sc r1, x >>>>> Your use of the atomic does not prevent stores reordering. >>>> >>>> If this is true, it sounds like the atomic(9) man page needs some revision. >>>> It says: >>>> >>>> When an atomic operation has acquire semantics, the effects of the >>>> operation must have completed before any subsequent load or store (by >>>> program order) is performed. Conversely, acquire semantics do not >>>> require that prior loads or stores have completed before the atomic >>>> operation is performed. >>>> >>>> Up until now, I have relied on this description of the way acquire barriers >>>> work. If this description is incorrect, I think it is important to fix it >>>> quickly. >> >> I think it is correct, but bit confusing. Its first sentence says that >> the acquire operation acts as if it completes before any subsequent load >> or store operation (even non-atomic ones; even to different locations; is >> it really that strong?) starts. Its second sentence is redundant except > Yes, all operations that are sequenced before/after, in the intra-thread > sence of ordering by sequential points. > >> for "Conversely". Completion of earlier operations is before the acquire >> operation is not the converse of starting of later operations after the >> acquire operation. >> >> So the acquire operation gives a sort of read-write barrier that is >> obviously not very useful by itself. Using only acquire operations, I >> don't see how to order anything except other acquire operations: >> >> acquire1 >> load/store1 # can be any time after acquire1 >> acquire2 # must be after acquire1 >> load/store2 # can be any time after acquire2 >> >> Since load/store1 may be delayed until after acquire2, it may be mixed >> with load/store2 in any order in general. > This is not useful at all, since it would only affect the current thread > behaviour, which is already guaranteed to be self-consistent. You need > other thread which observes current thread behaviour, for the barriers > to have any visible effect. > > And then, if there is other thread, 'sync with' is only established for > acq/rel pairs. Yes, I forgot that the ordering requires cooperation. So the man page is very misleading where it says "the effects of the operation must have completed". Only loads in the operation must have completed. atomic_add_acq_xxx() must also do something special with the store for the operation to be atomic. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170611231933.F767>