Double Factory pattern purposal as replacement for Double Check #2

Question

Hi All,
Here is the code for the pattern proposal, its intended as a replacement for double checked locking, which was proved to be broken in 2001. Here is the code...
public class DoubleFactory {
   private static Object second_reference = null;
   public static Object getInstance() {
      Object toRet = second_reference;
         if (toRet == null) {
            second_reference = CreationFactory.createInstance();
            toRet = second_reference;
      return toRet;
   private DoubleFactory() {}
public class CreationFactory {
   private static Object instance = null;
   public static synchronized Object createInstance() {
      if (instance == null) {
         instance = new Object();
      return instance;
  }Also I have spent several months discussing this with Peter Haggar, who believes that this code is not guaranteed to work. However I have been unable to discern from his message why he believes this will not be guaranteed to work, and I am posting this here to attempt to find a clearer explanation or confirmation that the pattern I am purposing (Double Factory) is guaranteed to work.
Thanks,
Scott
---------------------------- Original Message ----------------------------
Subject: Re: [Fwd: Double Factory replacement for Double Check #2] From:
"Scott Morgan" <[email protected]>
Date: Fri, January 25, 2008 10:36 pm
To: "Peter Haggar" <[email protected]>
Hi Peter,
I appologize if my last response came accross as rude or something. If
my code is not guaranteed to work ok, can you help me understand why. I
am after all looking for a solution for all of us.
If my solution is wrong as you say because the member variables of the
singleton are not up to date. I understand this to mean that the
second_reference pointer is assigned to the memory where the instance
object will get created before the instance object even starts the
creation process (when the jvm allocates memory and then enters the
constructor method of the Singleton). This doesn't seem possible to me.
Can you refrase your statments, to help me understand your points?
If not I am happy to turn to the original wiki for discussion.
Thanks for your effort,
Scott
Thanks for asking my opinion, many times, then telling me I'm
wrong...wonderful. You are a piece of work my friend. For what it'sworth, your email below shows you still don't understand these issues
or what I was saying in my emails. I've been more than patient.
>
All the best. And by the way, your code is not guaranteed to work. It's not just me that's "wrong", it's also the engineers at Sun who
designed Java, the JVM, and the memory model, and countless people who
have studied it. I'm glad you have it all figured out.
>
Peter
"Scott Morgan" <[email protected]>
01/18/2008 12:47 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks I understand your position now. However am I still believe that
it will work and be safe;
1) the Singleton you show would be fully constructed (having exited theSingleton() method) before the createInstance() method would have
returned.
2) The second_reference could not be assigned until the createInstance()
method returns.
3) So by the time second_reference points to Singleton all of the valueswill be set.
>
>
I do understand that if the createInstance method was not synchronized(at the CreationFactory class level) that my logic would be flawed, but
since there is synchronization on that method these points are true, and
your comments about up-to-date values are not accurate.
>
Cheers,
Scott
>In your listing from your latest email T2 does encounter a sync block
on createInstance.
>>>>
No. T2 will call getInstance and see second_reference as non-null.second_reference was made non-null by T1.
>>
>>>>
What are you exactly are you refering to with the phrase 'up-to-datevalues'?
>>>>
Assume my singleton ctor is thus:
public class Singleton
private int i;
private long l;
private String str;
public Singleton()
i = 5;
l = 10;
str = "Hello";
T2 will get a reference to the Singleton object. However, because youaccess second_reference without synchronization it may not see i as 5,
l as 10 and str as "Hello". It may see any of them as 0 or null. This
is not the out of order write problem, but is a general visibility
problem because you are accessing a variable without proper
synchronization.
>>
Peter
"Scott Morgan" <[email protected]>
01/16/2008 11:38 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
In your listing from your latest email T2 does encounter a sync blockon createInstance.
>>
What are you exactly are you refering to with the phrase 'up-to-datevalues'?
In this code the Singleton should also be
A) non mutable (as in the instance of class Object in the example).
If the singleton was more complex then the code to populate it'svalues
would go inside the sync of createInstance().
B) mutable with synchronization on it's mutator methods.
In your article you mention out of order writes, which doesn't occurin
this code.
Cheers,
Scott
You read it wrong.
- T1 calls getInstance which in turn calls createInstance.
- T1 constructs the singleton in createInstance and returns to
getInstance.
- T1 sets second_reference to the singleton returned in getInstance. -T1 goes about its business.
- T2 calls createInstance.
- T2 sees second_reference as non-null and returns it
- Since T2 accessed second_reference without sync, there is noguarantee
that T2 will see the up-to-date values for what this object refers to.
- Therefore the code is not guaranteed to work.
>>>
If this is not clear:
- Re-read my email below
- Re-read my article
- If still not clear, google on Double Checked Locking and readanything
from Brian Goetz or Bill Pugh.
Peter
"Scott Morgan" <[email protected]>
01/13/2008 05:26 AM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks for the reply, I don't see how T2 would see the a referenceto
a
partialy initialized object before the createInstance() method had
returned. If T1 was in createInstance() when T2 entered
getInstance(), T2 would wait on the CreationFactory's class monitor to
wait to enter createInstance().
Or in other words in the line of code ....
second_reference = CreationFactory.createInstance();
The pointer second_reference couldn't be assigned to the singleton
instance when the synchronized createInstance() had fully constructed,initialized and returned the singleton instance. Before that the the
second_reference pointer would always be assigned to null. So any
thread entering getInstance() before createInstance() had returned
(for the first time) would wait on the CreationFactory's class monitor
and enter the createInstance() method.
>>>
So T2 will wait for T1.
Cheers,
Scott
PS I think I am writing requirements for my next project :)
Sorry for the delay...been in all day meetings this week.
You are correct...I had been reading your code wrong, my apologies.
My explanations, although correct, did not exactly correspond to your
code.
However, the code is still not guaranteed to work. Here's why:
Assume T1 calls getInstance() which calls createInstance() and returnsthe
singelton. It then sets second_reference to refer to that singleton.
So
far, so good. Now, T2 executes and calls getInstance(). It can see
second_reference as non-null, so it simply returns it. But, there
was
no
synchronization in T2's code path. So there's no guarantee that even
if
T2 sees an up-to-date value for the reference, that it will seeup-to-date
values for anything else, ie what the object refers to...it's
instance data. If T2 used synchronization, it would ensure that it
read
up-to-date
values when it obtained the lock. Because it didn't, it could see
stale
values for the object's fields, which means it could see a partially
constructed object.
>>>>
In the typical double-checked locking, the mistake is to assume theworst
case is that two threads could race to initialize the object. But
the worst case is actually far worse -- that a thread uses an object
which
it
believes to be "fully baked" but which is in fact not.
Peter
"Scott Morgan" <[email protected]>
01/03/2008 06:33 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks for responding, I am still thinking that your mis
interpreting
the code so I have rewritten it here (Replacing
DoubleFactory.instance with DoubleFactory.second_reference for
clarity). If the T1 burps (gets interrupted) in the createInstance
method it wouldn't have returned so the second_reference pointer
would have never been
assigned
so T2 would just try again upon entering the getInstance method. Orif
it had already entered getInstance it would be waiting to enter
(until T1 releases the lock on CreationFactory.class ) on the
createInstance method.
>>>>
public class DoubleFactory {
private static Object second_reference = null;
public static Object getInstance() {
Object toRet = second_reference;
if (toRet == null) {
second_reference =
CreationFactory.createInstance();
toRet = second_reference;
return toRet;
private DoubleFactory() {}
public class CreationFactory {
private static Object instance = null;
public static synchronized Object createInstance() {
if (instance == null) {
instance = new Object();
return instance;
Does this clear up my idea at all?
second_reference should be always pointing to
null
or
a fully initialized Object
(also referenced by the pointer named 'instance' ), I don't see howit would end up partially initialized.
>>>>
Thanks Again,
Scott
"It" refers to T2.
Your createInstance method is identical to my Listing 2 and is fine
and
will work.
Yes, the problem with your code is in getInstance.
>I don't see how the DoubleFactory getInstance method could bereturning
a partially initialized object at this point. If CreationFactoryalways
returns a fully initialized object and DoubleFactory only assigns a
new
reference/pointer to it how could DoubleFactory getInstance return a
reference/pointer to partially initialized object?
>>>>>>>
>>>>>
The reason it is not guaranteed to work is explained in my previousemails
and in detail in the article. However, I'll try again. Anytime you
access shared variables from multiple threads without proper
synchronization, your code is not guaranteed to work. Threads are
allowed
to keep private working memory separate from main memory. There are
2
distinct points where private working memory is reconciled with main
memory:
- When using a synchronized method or block - on acquisition of thelock
and when it is released.
- If the variable is declared volatile - on each read or write of
that
volatile variable. (Note, this was broken in pre 1.5 JVMs which isthe
reason for the caveat I previously mentioned)
Your createInstance method uses synchronization, therefore, the
reconciliation happens on lock acquisition and lock release. T1 can
acquire the lock in createInstance, make some updates (ie create an
object, run it's ctor etc), but then get interrupted before exiting
createInstance and therefore before releasing the lock. Therefore,
T1
has
not released the lock and reconciled its private working memory withmain
memory. Therefore, you have ZERO guarantee about the state of mainmemory
from another threads perspective. Now, T2 comes along and accesses
"instance" from main memory in your getInstance method. What will
T2
see?
Since it is not properly synchronized, you cannot guarantee that T2sees
the values that T1 is working with since T1 may not have completely
flushed its private working memory back to main memory. Maybe it
did completely flush it, maybe it didn't. Since T1 still hold the
lock,
you
cannot guarantee what has transpired. Maybe your JVM is not usingprivate
working memory. However, maybe the JVM your code runs on does or
will
some day.
Bottom line: Your code is not properly synchronized and is notguaranteed
to work. I hope this helps.
Peter
"Scott Morgan" <[email protected]>
01/03/2008 12:49 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks for your response, I don't follow what 'it' refers to in
the
phrase 'It can see'. So for the same reason that you state that
example 2 from your article I believe this class CreationFactory to
work flawlessly when a client object calls the createInstance
method.
>>>>>
I see this CreationFactory code as identical to your example 2 doyou agree with this?
>>>>>
public class CreationFactory {
private static Object instance = null;
public static synchronized Object createInstance() {
if (instance == null) {
instance = new Object();
return instance;
}Then my rational in the DoubleFactory class is that it can obtain a
reference/pointer to the fully initialized object returned bycalling the above code. I believe you think that the problem with
my code is
in
the DoubleFactorys getInstance method, is this correct?
I don't see how the DoubleFactory getInstance method could bereturning
a partially initialized object at this point. If CreationFactory
always
returns a fully initialized object and DoubleFactory only assigns a
new
reference/pointer to it how could DoubleFactory getInstance return a
reference/pointer to partially initialized object?
>>>>>
Thanks again,
Scott
public static synchronized Singleton getInstance() //0
if (instance == null) //1
instance = new Singleton(); //2
return instance; //3
This above code is fine and will work flawlessly.
Annotating my paragraph:
T1 calls getInstance() and obtains the class lock at //0. T1 "sees"
instance as null at //1 and therefore executes: instance = new
Singleton() at //2. Now, instance = new Singleton() is made up of
several lines of non-atomic code. Therefore, T1 could be
interrupted
after Singleton is created but before Singleton's ctor isrun...somewhere
before all of //2 completes. T1 could also be interrupted after
//2 completes, but before exiting the method at //3. Since T1 has
not
exited
its synchronized block it has not flushed its cache. Now assume T2
then
calls getInstance().
All still true to this point. However, with your code the nextparagraph
is possible, with the code above, it's not. The reason is that T2
would
never enter getInstance() above at //0 because T1 holds the lock. T2will
block until T1 exits and flushes it's cache. Therefore, the code
above
is
properly thread safe.
It can "see" instance to be non-null and thus
return it. It will return a valid object, but one in which its ctor
has
not yet run or an object whose
values have not all been fully flushed since T1 has not exited itssync
block.
"Scott Morgan" <[email protected]>
01/02/2008 06:10 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks for the response I understand the rational for inventing
the
double check anti pattern, I am sorry I still don't understand the
difference between your solution #2 and my CreationFactory class.
>>>>>>
From your article figure 2.public static synchronized Singleton getInstance() //0
if (instance == null) //1
instance = new Singleton(); //2
return instance; //3
If I understand your email correctly this figure 2 is also flawed,since...
>>>>>>
T1 calls getInstance() and obtains the class lock at //0. T1 "sees"
instance as null at //1 and therefore executes: instance = new
Singleton() at //2. Now, instance = new Singleton() is made up ofseveral lines of non-atomic code. Therefore, T1 could be
interrupted
after Singleton is created but before Singleton's ctor isrun...somewhere
before all of //2 completes. T1 could also be interrupted after
//2 completes, but before exiting the method at //3. Since T1 has
not
exited
its synchronized block it has not flushed its cache. Now assume T2
then
calls getInstance(). It can "see" instance to be non-null and thus
return it. It will return a valid object, but one in which its
ctor
has
not yet run or an object whose
values have not all been fully flushed since T1 has not exited itssync
block.
So is #2 is also flawed for this reason?
If so please revise your article, since I interpreted #2 as a
plausible
solution recommended by you (which lead me to the DoubleFactory
idea).
If not please help me understand the difference between #2 and my
CreationFactory class.
>>>>>>
Thanks,
Scott
#2 is in Listing 2 in the article. What I meant was to forget the
DCL
idiom, and just synchronize the method...that's what listing 2
shows.
DCL
was invented to attempt to get rid of the synchronization for 99.9%
of
the
accesses.
The solution I outlined in my email is using the DCL idiom, but on
a
1.5
or later JVM and using volatile.
You solution is not guaranteed to work. Here's why:
public class DoubleFactory {
private static Object instance = null;
public static Object getInstance() {
Object toRet = instance;
if (toRet == null) {
instance =
CreationFactory.createInstance();
toRet = instance;
return toRet;
private DoubleFactory() {}
public class CreationFactory {
private static Object instance = null;
public static synchronized ObjectcreateInstance()
//1
if (instance == null) {
instance = new Object(); //2
return instance;
} //3
}T1 calls createInstance() and obtains the class lock at //1. T1"sees"
instance as null and therefore executes: instance = new Object() at//2.
Now, instance = new Object() is made up of several lines of
non-atomic
code. Therefore, T1 could be interrupted after Object is created
but
before Object's ctor is run...somewhere before all of //2
completes.
T1
could also be interrupted after //2 completes, but before exiting
the
method at //3. Since T1 has not exited its synchronized block ithas
not
flushed its cache. Now assume T2 then calls getInstance(). It can"see"
instance to be non-null and thus return it. It will return a
valid object, but one in which its ctor has not yet run or an
object
whose
values have not all been fully flushed since T1 has not exited itssync
block.
The bottom line is that if you are accessing shared variables
between
multiple threads without proper protection, you are open for aproblem.
Proper protection is defined as: proper synchronization pre 1.5,
and
proper synchronization or proper use of volatile 1.5 or after.
Therefore, if you must use the DCL idiom you have one option: -
Use DCL with volatile on a 1.5 or later JVM.
>>>>>>>
You can also forget about DCL and just use synchronization (listing2
in
my article) or use a static field (listing 10 in my article).
I hope this clears it up.
Peter
"Scott Morgan" <[email protected]>
01/02/2008 04:00 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
Re: [Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
I apologies for not understanding but I don't see what is
different
between the solution you purposed...
2) Don't use DCL but use synchronization
and the code that I am putting forward. Perhaps I do just notunderstand
but you seem to be contradicting yourself in this email?
I understand that you are saying in #2 that this will always 'work'
with
out any issues...
public static Object instance = null;
public static synchronized Object getInstance() {
if (instance == null) {
instance = new Object();
return instance;
But first you seem to say in the email that if T1 gets
interrupted
it
may leave the instance pointing to a partially initialized object?
So as far as I understand it the createInstance method in my
CreationFactory class should be successful (always retuning a
fully initialized object) for the same reason #2 is successful.
Please keep in mind that there are two different instancepointers
in
the code I sent you, one is part of the DoubleFactory class and
the other is part of the CreationFactory class.
>>>>>>>
Thanks for your time, just looking for better solutions!
Scott
Scott,
Your solution is not guaranteed to work for various reasons
outlined
in
the article. For example, you can still return from your code apartially
initialized object. This can occur if T1 gets interrupted beforeleaving
the synchronized method createInstance() and T2 calls
getInstance().
T2
can "see" toRet/instance as non-null but partially initialized
since
T1
has not fully flushed its values.
As of 1.5, Sun fixed various issues with the memory model that
were
broken. Double Checked Locking will still break unless you usevolatile
(which was fixed in 1.5). Therefore, the following code works:
volatile Helper helper;
Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
return helper;
but the original DCL idiom will not work. So, your options are:
1) Use DCL with volatile (above)
2) Don't use DCL but use synchronization
3) Don't use DCL, but use a static field.
#2 and #3 are outlined in my article from 2002.
Hope this helps,
Peter
"Scott Morgan" <[email protected]>
12/26/2007 04:12 PM
Please respond to
[email protected]
To
Peter Haggar/Raleigh/IBM@IBMUS
cc
Subject
[Fwd: Double Factory replacement for Double Check #2]
Hi Peter,
Thanks for the article on the out of order write problem. Whatdo
you
think of this as a solution?
TIA,
Scott
---------------------------- Original Message----------------------------
Subject: Double Factory replacement for Double Check #2
From: "Scott Morgan" <[email protected]>
Date: Wed, December 26, 2007 2:55 pm
To: [email protected]
Hi Ward,
Here is a pattern submission
Double Factory
Lazy initialization of singletons in accepted for a while usingthe
double check pattern. However it has been discovered that the
double
check pattern isn't thread safe because of the out of order write
problem. This problem occurs when Threads entering the Singleton
Factory method return with a fully constructed, but partially
initialized, Singleton object.
>>>>>>>>
Therefore: It makes sense to look for a way to initializeSingletons
in
a Lazy and Thread Safe manor. The following illustrates a fairly
simple
solution...
package foo;
public class DoubleFactory {
private static Object instance = null;
public static Object getInstance() {
Object toRet = instance;
if (toRet == null) {
instance =
CreationFactory.createInstance();
toRet = instance;
return toRet;
private DoubleFactory() {}
public class CreationFactory {
private static Object instance = null;
public static synchronized ObjectcreateInstance()
if (instance == null) {
instance = new Object();
return instance;
This gets around the out of order write problem because all
Threads
waiting on the CreationFactory's Class monitor will have a fully
constructed and initialized instance when they actually exit the
createInstance method.
>>>>>>>>
>>>>>>>>
During runtime while the Singleton instance is getting created(constructed and initialized) there may be a few Threads waiting
on
the
CreationFactory Class's objects monitor. After that period all
the
Treads
accessing
the Singleton will have unsynchronized reads to the instance,
which
will
optimize execution.
References:
http://www.ibm.com/developerworks/java/library/j-dcl.html
Copyright 2007 Adligo Inc.

Answer 1

Scott-Morgan wrote:
Hi All,
Thanks for your comments, here are some more....
jtahlborn you state that
the only way to guarantee that a (non-final) reference assignment is visible across threads is through the use of volatile and synchronized,
From the jvm spec
http://java.sun.com/docs/books/jls/third_edition/html/memory.html
17.4.1 Shared Variables
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields and array elements are stored in heap memory.
Since both the second_reference and instance fields are both static, they are shared and visible across all threads.Yes, all these things are shared across threads, however, if you keep reading, there is a notion of "correct" sharing. obviously these values may be visible, that's why double-checked locking was used for so long before people realized it was broken. it worked most of the time, except when it didn't, and that's what i'm trying to show. that the only way to correctly share state between threads is via synchronization points, the most common being volatile and synchronized (there are a couple of other less used ones which don't apply here). The articles you linked to below from ibm cover the "visibility" in great depth, this is exactly what i am referring to.
You also state that volatile is a solution, but you seem to rebut your self in stating that the overhead for volatile is almost as great as synchronization.
This article illustrates the solution, and also comments on the overhead of volatile.
http://www.ibm.com/developerworks/library/j-jtp03304/
linked from
http://www.ibm.com/developerworks/java/library/j-dcl.html
volatile is a solution, in that it is correct, and you avoid the appearance of synchronization each time. however, since the semantics of volatile were strengthened in the new memory model, using volatile will perform practically (if not exactly) the same as simply synchronizing each time. the article you link to says exactly this under the heading "Does this fix the double-checked locking problem?".
Also could you be more specific about the example at the end of the jvm memory spec page, like a section number?It's the very last thing on the page, the "discussion" under 17.9, where it mentions that changes to "this.done" made by other threads may never be visible to the current thread.