> 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
rules
// 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
the
problem.
David
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT