[concurrency-interest] Java Memory Model versus dotnet MemoryModel

David Holmes dholmes at dltech.com.au
Thu Nov 3 19:57:44 EST 2005

> 1) In order to come up with a well constructed
> multithreaded Java app guaranteed to work properly on
> any multicore chips when using Java 1.4 down, one must
> consider as invalid certain idioms and advices from
> Sun and others, and use the old Ada and Modula3
> technique of synchronizing all accesses to shared
> variables, including those qualified as final and
> including those of type String. (The situation is
> better, i.e., less restrictive and allowing better
> performance, when using Java 5.)

There are two kinds of guarantee here:

a) what does the Java platform guarantee
b) what does a specific implementation of Java provide on a given platform

For (a) then pre Java 5 - yes certain idioms and coding practices are
technically incorrect and not guaranteed to work by the rules of the

However for (b) a given implementation is always more constrained than the
spec and actually provides tighter behaviour. For example, I believe that
Sun's JDK 1.4.2 implements volatile semantics in a way that is consistent
with the Java 5 memory model.

Depending on what kind of "guarantee" you are after, you may be able to use
pre Java 5 software in its existing form.

Given that multi-core chips are supposed to be transparent to the software
(ie the software can't tell if it is running on multi-core or SMP) then I
don't expect to suddenly see problems with software that ran on a SMP before
and is now run on multi-core. Of course, software that has only run on a
single processor before may well exhibit previously undetected concurrency
bugs when run with multiple processors and/or cores.

David Holmes

More information about the Concurrency-interest mailing list