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 <kostik...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
