>If I remember correctly, this is what could happen: > >(1) Thread 1 sees that instance==null. >(2) Thread 1 synchronizes on the synchronizer. >(3) Thread 1 allocates X bytes of memory for a FileCache. >(4) Thread 1 sets instance=(pointer to the allocated memory). >(5) Thread 1 calls FileCache() constructor to initialize > the memory area that instance points to -- AFTER it has > already set the instance pointer! >(6) Thread 1 unlocks the synchronizer. >
The problem is that you could then have another thread that runs after step 4. It sees that instance is not null and attempts to use it. Ooops, it hasn't actually been constructed yet, so the program blows up. Now a reasonable person might expect that instance won't be set before the object is constructed, but there are at least two situations where this could go wrong. First, multiprocessor systems allow for reordering of writes. This can be fixed if you can insert the correct assembler statements which you can't in Java. Java allows for reordering of writes in some cases, and I think it can happen often with inlined stuff. There are way to fix this problem suggested in the new Java memory model but that doesn't help us right now. So right now, the code, as written, can break on multi-processor systems and can break on single-processor systems depending on what your java compiler does. -Tom _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
