WRONG, WRONG, WRONG....
>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 does not work. According to both the existing specification, and
proposed new specifications, the write to singletons[i] can be moved
inside the synchronized block.
Please do not try to make the double-check idiom work; you can't.
There is a way to guarantee the write ordering under the existing
JMM, but it is a secret ( :-) ), because I want to get rid of it in
the revised spec.
Bill
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:25 EDT