<grumpy> Its not a matter of whether you can get code to compile and work. The authors admit that under specific JVM implementations (perhaps even the majority) DCL can and does work. The fact remains, however, that the Java Memory Model does not explicitly guarantee the perceived order of writes or executions in multi-threaded environments.
For more information on this from Doug Lea, author of Concurrent Programming in Java, see http://gee.cs.oswego.edu/dl/cpj/jmm.html Its amusing that you think your isolated test cases "prove" that they are wrong. Negatives cannot be proven because of the problem of induction. It is only permissable to prove a negative by way of a positive that narrows its possibility out. While your test cases do serve to narrow the possibilities, one only has to look at the specification to realize that the possibilities are very cleared spelled out. If you choose to write code that can and probably will break under edge-case scenarios, more power to you. I'll choose to play it safe and code to the spec. I'm funny like that. I want my code to work. </grumpy> -----Original Message----- From: Alexey A. Efimov [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 9:26 AM To: [EMAIL PROTECTED] Subject: RE: [Eap-list] 614: Code Inspection, constant conditions & NPEs Try read http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html But I not agree with it's authors... I check it article, and more other - all of them contains not compiled code or not right code... My guess for this - it's just flame. More for all - I check with more test classes on diferent processors computer this code, and it's stay is stable. I think that IntelliJ team can fix analiser to support this. But team must make team-self decision. Thanks, and it all -----Original Message----- From: Maxim Shafirov [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 28, 2002 7:59 PM To: Cedric ROUVRAIS Subject: Re: [Eap-list] 614: Code Inspection, constant conditions & NPEs Hello Cedric, This topic had already been discussed in eap several days ago. As the matter of fact double synchronization does not makes what it intended to in the current implementation of JVM. -- Best regards, Maxim Shafirov JetBrains, Inc / IntelliJ Software http://www.intellij.com "Develop with pleasure!" CR> Hi, CR> The following code comes out as always false (second 'if (null)'): CR> public static ServiceManager getInstance() throws RaccoonException { CR> if (mServiceManager == null) { CR> synchronized(ServiceManager.class) { CR> /** We check if the singleton is still null */ CR> if (mServiceManager == null) { <= Code inspection yells here CR> mServiceManager = new ServiceManager(); CR> mServiceManager.setPropertyFileName("service"); CR> /** Initialise the ServiceLoader */ CR> mServiceManager.start(); CR> } CR> } CR> } CR> return mServiceManager; CR> } CR> Maybe a special case could be handled for code surrounded by CR> synchronized? CR> This is a very very low priority too me, but a nice to have :o) CR> a++ Cedric CR> _______________________________________________ CR> Eap-list mailing list CR> [EMAIL PROTECTED] CR> http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
