[concurrency-interest] Happens Before guarantee in case of unsafe.putOrderedObject and corresponding nomal read of a variable
vitalyd at gmail.com
Fri Sep 5 13:49:31 EDT 2014
lazySet orders preceding writes with the write being done as part of
lazySet, but does not guarantee that this write is globally visible before
next instruction is executed by the writing CPU. In practical terms, on
x86/64, this compiles into a plain mov instruction with a compiler barrier
prevent prior stores from moving past the lazy one. If this store were
done via volatile write or AtomicXXX.set(), then a cpu serializing
instruction would be added after the store (e.g. lock add $0, %rsp).
I'm guessing on non-TSO platforms lazySet implies a weaker release fence
instruction is emitted, but I don't know the details.
On Fri, Sep 5, 2014 at 1:14 PM, Justin Sampson <jsampson at guidewire.com>
> Andrew Haley wrote:
> > And again: I thought the idea of lazySet was to *weaken* the
> > guarantee. Otherwise I don't know what it is for.
> My own _guess_ based on the docs is that a full-volatile write ensures a
> happens-before relation with _all_ subsequent volatile reads of the same
> field, whereas a lazy/ordered write ensures a happens-before relation
> with any subsequent volatile read _that sees the value written_ by that
> write. Therefore lazy writes guarantee, for example, safe publication
> of objects, without actually forcing everything immediately out to main
> memory. But all bets are off, of course, if the read itself is not a
> volatile read.
> Doug et al., how close am I?
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest