[concurrency-interest] Synchronization of data read by multiple threads

Doug Lea dl at cs.oswego.edu
Wed Oct 26 11:11:23 EDT 2005

Gregg Wonderly wrote:
> If I decide that I want my software loop to be controlled by a lazy read 
> on an unsynchornized/non-volatile value so that eventually, it changes 
> its behavior based on that value, but I don't care when, there is no 
> means to do that given what the JMM says.

Most of the posts so far focussed on correctness, which is of
course primary. Here are a couple of notes on performance side:

You should find it comforting that on nearly all processors,
a volatile read costs no more than any other kind of read,
except that compiler/VM/processors cannot retain/cache values in
registers etc. Since you seem to want exactly this effect in
these cases, volatile is just want you want conceptually as well.

Volatile writes on the other hand cost almost as much in terms of
underlying barriers as synchronized blocks. Similarly for compareAndSet
on atomics. Although both are still are normally cheaper than locks 
because they never block on locks when contended. Except that if
you have a lot of memory contention retrying compareAndSets
and the like, you are usually better off using locks or related
synchronizations to cause some of those threads to block rather than
fight for cache lines etc.

So, basically, the story on the performance side meshes pretty
well with that on the correctness side. So don't worry, just be
happy and obey the rules :-)


More information about the Concurrency-interest mailing list