Re: JavaMemoryModel: Problem on single processor

From: David Holmes (
Date: Wed May 24 2000 - 22:43:29 EDT

> Anyone have thoughts on why double-check would fail on a single processor?

If the writes of the reference and the associated fields are reordered then
a second thread may see the reference as non-null but still see the fields
in their un-initialized state (at the point that the second thread sees the
fields the first thread has not yet exited the synchronised block).

Why this seems to be specific to a particular VM version - I guess it
depends on what code the JIT produces.

As you noted in your emails the double-check pattern suffers from two
potential error sources: write reordering and read-reordering. Write
reordering can occur even on uni-processors. A solution to the write
reordering problem is to add an extra step to the write path and use a
second synchronized block:

if (singletons[i] == null) {
   synchronized(singletons[i]) {
       synchronized (singletons[i]) {
           temp = new Singleton();
       } // temp fields are now forced to memory: assuming the JVM obeys MM
         // when dealing with recursive locks.

       singletons[i] = temp;
    } // reference now forced to main memory

This, of course, does not solve potential read-reordering problems.

Try and dig out an archive of Dave Butenhof's various postings to
comp.programming.threads on this subject, for a non Java specific view of


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT