In this video about Disruptor, a concurrency framework, the lazySet method of Java\'s Atomic* classes (e.g. AtomicLong) is mentioned. According to the documentation, this method
This basically calls to unsafe.putOrderedLong()
which is a native function. Based on the distinction made in unsafe between ordered (lazy) vs volatile (immediate). I am nearly certain that the (lazy) version simply resolves to a storestore
while volatile requires the more expensive loadstore
. This preserves threading semantics (for the setting thread) without halting all other cores. Eventually the readers will pickup the new value.
[Edit: That said (which is speculative), I am certain that the lazy store uses 'lighter' memory fencing that used by the full volatile -- if the platform provides it. E.g. I don't see what you can't do the same in C#, say for x86]
Typical use of something like this is a counter (say queue depth). If you hit a volatile on every iteration, it will not be "high performance" as you incur the full cost of cache coherence in each iteration. If your concurrent interaction permits 'fuzzy' readings then your (interacting via memory) then this technique reduces the cost of maintaing total system state (within an acceptable range of error e.g. your reading of queue depth is a bit off.)
[p.s./edit: discussion of fencing by Distruptor's designers.]