[concurrency-interest] Single writer multiple readers no barriers -- safe ?

Aaron Grunthal 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 
Thomas' example.


More information about the Concurrency-interest mailing list