RE: [Eap-list] BUG: Code Inspection: Singleton not recognized ( now OT: Double Checked Locking is Broken )

[Brian Majewski]

Title: Сообщение

can we move this private?   btw - DCL is broken, Sun even admits it.   http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html - Cliff Click of the HotSpot JVM project is one of the authors.       Brian Majewski Systems Architect Chrome Systems Corporation [EMAIL PROTECTED] PHONE: +1-503-963-6410 / +1-800-936-8906 FAX: +1-503-963-6312 www.chrome.com Notice:  This e-mail transmission and/or the attachments accompanying it may contain confidential information belonging to the sender or Chrome Systems Corporation.  The information is only for the use of the intended recipient.  If you have received this transmission in error, please notify the sender immediately by reply e-mail, and then destroy all copies of the transmission. -----Original Message----- From: Alexey A. Efimov [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 11:11 AM To: [EMAIL PROTECTED] Subject: RE: [Eap-list] BUG: Code Inspection: Singleton not recognized Mike, No i never, but i read this. And want to say. It's not compitent and non tested 'flame'. I forget about any words closly memmory organisation, it's no target for me now, but i have any question by this theme.   OK let's describe, The code from this article even not tested: class SomeClass {   private Resource resource = null;   public Resource getResource() {     if (resource == null) {       synchronized {         if (resource == null)           resource = new Resource();       }     }     return resource;   } }   Do you compile this? :) By specification synchronize must be with variable (http://java.sun.com/docs/books/jls/second_edition/html/statements.doc.html#255769). This is no mather, realy.   If you about this:   So what's broken about DCL? DCL relies on an unsynchronized use of the resource field. That appears to be harmless, but it is not. To see why, imagine that thread A is inside the synchronized block, executing the statement resource = new Resource(); while thread B is just entering getResource(). Consider the effect on memory of this initialization. Memory for the new Resource object will be allocated; the constructor for Resource will be called, initializing the member fields of the new object; and the field resource of SomeClass will be assigned a reference to the newly created object. However, since thread B is not executing inside a synchronized block, it may see these memory operations in a different order than the one thread A executes. It could be the case that B sees these events in the following order (and the compiler is also free to reorder the instructions like this): allocate memory, assign reference to resource, call constructor. Suppose thread B comes along after the memory has been allocated and the resource field is set, but before the constructor is called. It sees that resource is not null, skips the synchronized block, and returns a reference to a partially constructed Resource! Needless to say, the result is neither expected nor desired. When presented with this example, many people are skeptical at first. Many highly intelligent programmers have tried to fix DCL so that it does work, but none of these supposedly fixed versions work either. It should be noted that DCL might, in fact, work on some versions of some JVMs -- as few JVMs actually implement the JMM properly. However, you don't want the correctness of your programs to rely on implementation details -- especially errors -- specific to the particular version of the particular JVM you use. Other concurrency hazards are embedded in DCL -- and in any unsynchronized reference to memory written by another thread, even harmless-looking reads. Suppose thread A has completed initializing the Resource and exits the synchronized block as thread B enters getResource(). Now the Resource is fully initialized, and thread A flushes its local memory out to main memory. The resource's fields may reference other objects stored in memory through its member fields, which will also be flushed out. While thread B may see a valid reference to the newly created Resource, because it didn't perform a read barrier, it could still see stale values of resource's member fields.   I'm answer. Even if in case of condition "if (instance == null)" - about this condition says article, even is instance already not null but memmory not allocated this no fatal happends, becose reference controlled by JVM, and if JVM say "The instance is not NULL" then it's true, and referense did not come sudenly to other value. Exactly it WORKS PROPERTLY - return already innitialized instance, but not tryed reinitilise it. I guess.   If we look end of article, we see code about static singleton. This from book of templates that writed greated of programmers guys - Bruce Eckel. And i think that if author of article read his book "Thinking in Java", tryes code closely 10 web application, then author say - "it realy works, i tested".   This is my private opinion. Maybe very presumptuously opinion, but my. And i don't change my point of view on singleton's use and how i can used singletons.   Thanks. -----Original Message----- From: Mike Aizatsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 9:04 PM To: [EMAIL PROTECTED] Subject: RE: [Eap-list] BUG: Code Inspection: Singleton not recognized Alexey,   Have you seen this article <http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html>? Best regards, Mike Aizatsky. ------------------------------ JetBrains, Inc / IntelliJ Software http://www.intellij.com "Develop with pleasure!"