Date: Sun, 11 Jun 2017 16:01:59 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: 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: <20170611130159.GR2088@kib.kiev.ua> In-Reply-To: <20170611150813.B891@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > Release operations give an ordering that pairs correctly with acquire > operations. Essentially what is misdescribed as the "converse" above. > > > There are many issues with the atomic(9) man page, and they are not easy > > to fix. In essence, useful, implementable and rigorous specification of > > the atomics behaviour or the memory model as whole (which cannot be avoided > > if atomics are specified) seems to be still somewhat unsolved scientific > > problem. > > > > As is, I strongly suggest to rely on the standard C or C++ > > specifications and augment it with some code reading of > > arch/include/atomic.h. Despite it is unfeasible to use compiler-provided > > atomics in kernel in C runtime, the intended behaviour as specified in > > standards give us a strong base to get something that does not have > > inherent design mistakes. Unfortunately, this is the only way to get it > > correct now. > > But the standards are even harder to read (since they are more formal and > more general). Sure, but there is large community and literature discussing and exploring the standard. While for atomic(9) there is several people which sometimes discuss it on lists.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170611130159.GR2088>