Ok, but the guarentee is only with respect the object reference, and the construct still seems subject the the critiques of the double-check idiom made in the Josuha Block book, in particular:
<quote Effective Java, item 48, page 193> That a thread can observe the lazily constructed object in a particully initialized state is wildly conterintuitive. The object is fully constructed before the reference is "published" in the field from which it is read by other threads (foo). But in the absence of synchronization, reading a "published" object reference. does not guarentee that a thread will see all of the data that were stored in memory prior to the publication of the object reference. In particular, reading a published object reference does not guarentee that that reading thread will see the most recent values of the data that consititue the internals of the referenced object. In general, the double-check idiom does not work, although it does work if the shared variable contains a primative value rather than an object reference [Pugh01b]. </quote Effective Java, item 48, page 193> So, I question whether there is any guarentee that the someOtherMethod's attempt to access an interator will see a consistent copy of the HashMap since this access is occuring without synchronization. I need to lookup the referenced Pugh doc which lists a URL of: http://www.cs.umd.edu/~pugh/java/memory/Model/DoubleCheckedLocking.html xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Adrian Brock" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 13, 2003 9:54 AM Subject: Re: [JBoss-dev] Why are we using this bogus construct > Hi Scott, > > This is copy on write. > It works best when modifications are infrequent > compared to access. > e.g. connecting to a jms topic (modification) > and broadcasting messages to the connections (iteration). > > Dain's version would copy on every message, rather than > only when a client connects/disconnects. > > According to the java language spec > > synchronized(clients) > { > ... > clients=copy; > } > > clients is an expression re-evaluated before entry > into the block. > Once clients is replaced with the copied object > another thread is elected to run. > Any other waiting threads go back to > sleep, waiting on the new version of clients. > > Any current iterations effectively use a "snapshot" of > clients from before the modification so don't need > to synchronize (it will never be modified). > But, this means the pattern cannot be used when access > and modification need to see the same version. > It also means you cannot use iterator.remove() > > Regards, > Adrian ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
