Here are links to many articles discussing this issue in JavaWorld last
year:

http://www.javaworld.com/isearch?qt=double+check&site=javaworld&ms=1&tid=1&s
t=1&rf=0&x=67&y=1

-----Original Message-----
From: Pete Kazmier [mailto:[EMAIL PROTECTED]]
Sent: March 13, 2002 7:55 AM
To: [EMAIL PROTECTED]
Subject: JCS - Double-check idiom?


While reading item #48 in the Effective Java book, I came across a few
paragraphs that discuss the potential pitfalls of using the double-check
idiom in a multi-threaded application.  I recall seeing in the commit
logs that this idiom has been used in JCS.  As a result, I believe there
could be problems using JCS in a production environment.  However, I'm
by no means an expert in the subject matter, I'd appreciate opinions
from others.

For those of you with Bloch's book, please refer to pages 193 - 195.
The code that he refers to is the following (he doesn't follow our
coding convention :-)

   private static Foo foo = null;

   public static Foo getFoo() {
       if (foo == null) {
           synchronized (Foo.class) {
               if (foo == null)
                   foo = new Foo();
           }
       }
       return foo;
   }

Then the last paragraph on page 193 states:

  "That a thread can observe the lazily constructed object in a
   partially initialized state is wildly counterintuitive.  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 abscence of
   synchronization, reading a "published" object reference does not
   guarantee 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 guarantee
   that the reading thread will see the most recent values of the data
   that constitute 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 primitative value rather than an object
   reference [Pugh01b]."

Earlier in that section, he also states that problems of this nature
are much more likely to occur on multi-processor machines.

JCS uses a similiar idiom in several locations, for example, in
o.a.s.jcs.access.CacheAccess, the following appears:

   if ( cacheMgr == null )
   {
       synchronized ( CacheAccess.class )
       {
           if ( cacheMgr == null )
           {
               cacheMgr = CacheManagerFactory.getInstance();
           }
       }
   }

Does the problem Bloch describes apply here as well?

Thanks,
Pete

--
Peter Kazmier                                 http://www.kazmier.com
PGP Fingerprint   4FE7 8DA3 D0B5 9CAA 69DC  7243 1855 BC2E 4B43 5654

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to