[concurrency-interest] memory barriers

Doug Lea dl@cs.oswego.edu
Thu, 29 Jan 2004 07:38:37 -0500

> The question was really if the statement
> ------
> Changes to fields made by one thread are guaranteed to be visible to 
> other threads only under the following conditions:
> ...
> A writing thread releases a synchronization lock and a reading thread
> subsequently acquires that _same_ synchronization lock.
> ---------
> do it really need to be the _same_ synchronization lock?


And similarly, you can guarantee visibility using volatiles only if
you read the same volatile as the one written. Which explains why it
wouldn't do you much good to have a Thread.memoryBarrier operation.

The JSR133 revised Java memory model (in effect for JDK1.5) differs
from the old spec in establishing simple, uniform rules for these
cases. (There is also a new underlying abstract memory model.)
Sometime soon, JSR133 needs to put up the one-page programmer-oriented
summary of these. In the mean time, check out slides 17-18 of a talk I
did last month that covers some of this at

See also the JMM site for lots more information:

> They have something similar on the .NET platform

This is mainly because they don't place volatile memory semantics on
the variables, but instead on the operations. Hoping not to start a
language flame-war, I'll note only the main tradeoffs:

  * The .net approach is more amenable to allowing "manual" tweaks and
     micro-optimizations that in Java would need to be done by the JVM
     or platform-dependent Java-level "intrinsics" code. (However, 1.5
     hotspot (especially -server) and JDK support code apply more such
     optimizations than most programmers know about.)

  * The .net approach will be harder to support on non-SMP-like
     platforms, for example cluster-VMs and distributed shared memory,
     but Java's model will apply to these in a straightforward way even
     though the underlying implementations will be very different.