"David Holmes" <dholmes@dstc.edu.au> writes:
> > 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]) {
Surely you're joking. This is an open invitation for a NullPointerException.
> 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
Tom.
-------------------------------
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