[concurrency-interest] DCL using Fence Intrinsics
jsampson at guidewire.com
Sat Mar 14 00:37:25 EDT 2015
> So yes, theoretically you always want to put a loadFence there
> (assuming that we have only the existing fence intrinsics), but I
> don't think it's practically (now or in the future) necessary.
As a mere mortal trying to write reliable, portable code without
knowing the details of every processor that Oracle is planning to
support in HotSpot, "theoretically" is pretty important to me.
That said, what actually counts as a dependent load? Is it purely a
matter of dereferencing pointers? That works for final field
semantics, since they are carefully defined in the JMM in terms of
reachability (i.e. kind of like happens-before but not transitive
with other happens-before edges). So that covers Vikas's Code1 vs.
Code4, as long as all he cares about is anything reachable from that
specific object. But in Vikas's Code2/Code3, are 'a' and 'b'
actually "dependent" in any way? Neither one is a pointer, so
there's no question of reachability. The processor doesn't know of
any relationship between them. So surely we do need the load fence
both inside the loop and after it, right? Regardless of instruction
reordering, don't we have to worry about a variety of cache effects
More information about the Concurrency-interest