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]>
