[concurrency-interest] Single writer multiple readers no barriers -- safe ?
aaron.grunthal at infinite-source.de
Fri Nov 29 18:49:22 EST 2013
On 30.11.2013 00:13, Vitaly Davidovich wrote:
> If the field is volatile but accessed through unsafe direct member
> access, I'm not sure whether the access is treated as volatile or not in
> that case. However, I don't see the point in marking the field as
> volatile and accessing through unsafe and expecting compiler barrier -
> this is what AtomicReference.get() will achieve.
I've tried that a while ago and it looked like that a plain Unsafe read
to a volatile field (or a normal field for that matter) will not get
loop-hoisted. So it seems to sort-of act like a compiler barrier.
Whether that's intentional behavior or just an implementation detail was
never figured out.
Although it might be useful for concurrent data structures on non-x86
platforms to optimistically attempt a stale read to avoid
cache-coherency costs. I think I've seen a few places the j.u.c Classes
where that's done. If the compiler were free to reorder through the
plain unsafe reads it might yield more optimal assembly output.
But you always have the reverse option of accessing a normal field
through unsafe, which gives you a barrier-free reads if needed and all
the other ordering options as needed. But that's something for
fine-tuned algorithms where every single instruction counts and not for
More information about the Concurrency-interest