Design Pattern, Implementation Pattern and Best Practices

[kamsky]

@mark,

Your first solution is the code I posted. Yes, the drawback is you are doing repeated synchronized call.

Your other solution -- ill have to reread again, i think I need a small brain cycle and I dont have patient now coz Im working.

Anyway, the objective my question is just for just sharing.

The solution is called Double Checked Locking. It's pretty smart. See: Double-checked locking - Wikipedia, the free encyclopedia

I dont know if it's still applicable now.

Keep sharing guys.

[MarkCuering]

Bro, Walay STATIC CONSTRUCTOR ang JAVA? I'm looking on this: Java VS. C# : constructor pero naa siya STATIC BLOCK? can you make use of that static block to get rid of Synchorization.

In C#, static objects are loaded at runtime, meron na siya allocated memory, that's why it is expensive to have a lot of static objects... In .NET Classes, ang STATIC constructor loaded na automatically at runtime... so no need na to include synchronization if you want to apply a singleton pattern. Coz at runtime pa lang, initialized na ang singleton class mo.

I'm thinking sa STATIC BLOCK sa java... if the method/attributes are under sa static block, is it that during runtime autmatically loaded na ang members under static block? pakiverify nlng kay iyang example kay loaded na automatically.

class Test
{
    public static void main(String[] args) {
        A.F();
        B.F();
    }
}
class A
{
    static {
        System.out.println("Init A");
    }
    public static void F() {
        System.out.println("A.F");
    }
}
class B
{
    static {
        System.out.println("Init B");
    }
    public static void F() {
        System.out.println("B.F");
    }
}

ang output ay:

output: 
    Init A
    A.F
    Init B
    B.F

so kung imo ni e apply sa singleton class:

   static {
          public  Singleton getInstance()  {
                if (instance == null) {   instance = new Singleton();  }       
                return instance;
         }
    }

No need "synchronized", bisag mag lumba pa na imong mga thread, the singleton class is already initiated right before your thread becomes active.

[kamsky]

I did that similar to last code you posted and that's one of the solution too way back jdk1.4 -- (double checked lock doesnt work with 1.4).
Here's the Java equivalent by using private static inner class:

public class Singleton {
    
  private Singleton() {}
   
  public static Singleton getInstance() {
     return SingletonHolder.singleton;
  }
    
  private static class SingletonHolder {
     public static Singleton singleton = new Singleton();  
  }
}

There is static block in java but you cant have constructor in static.

Too many ways to kill a chicken no?

I am not sure what's the flaw of this. Probably it's possible to load classes several times and invoke new Singleton() many times too ?
i.e. multiple classloader found in app servers.

PS. Now I know one of the drawback. No lazy initialization.

[MarkCuering]

that one implements singleton, because of the "private static class SingletonHolder {}" can only be access at runtime.

But this won't work in C#, coz you declare the getInstance method as public, it means that, it is only accessible via instance of the class. However you decalre the constructor as private so there's no way to create an instance.

if we change it to:

public static Singleton getInstance()

I can have like this: Singleton T = Singleton.getInstance();

Console.WriteLine(Singleton.getInstance().GetHashC ode());
Console.WriteLine(Singleton.getInstance().GetHashC ode());
Console.WriteLine(Singleton.getInstance().GetHashC ode());
Console.WriteLine(Singleton.getInstance().GetHashC ode());

58225482
58225482
58225482
58225482
Press any key to continue .

. .

[kamsky]

@mark

actually my original code should be:

public static Singleton getInstance() {}

System.out.println(Singleton.getInstance().hashCode());
System.out.println(Singleton.getInstance().hashCode());
System.out.println(Singleton.getInstance().hashCode());
System.out.println(Singleton.getInstance().hashCode());

58225482
58225482
58225482
58225482
Press any key to continue .

and of course i just copied your hashCode.

To sum up, singleton might be the simplest design pattern. But just there are tricks around that might be worth the trouble.

[bluedes]

Problem: A thread instantiate a singleton, while it's not done instantiating, another thread instantiate the same singleton class. Now they are two instances.

So how do you ensure single instance in a Singleton in a multi-threaded environment?

how can a singleton be instantiated twice? the fact that its a singleton by design, it will remain a singleton.. depends on how you code your singleton..

when a thread calls the singleton for the very first time, it will instantiate itself once.. and threads share memory stack/heap, so there's no way another thread will create another singleton in the same memory stack/heap..

what kind of multithreading environment are you using?

[kamsky]

how can a singleton be instantiated twice? the fact that its a singleton by design, it will remain a singleton.. depends on how you code your singleton..

when a thread calls the singleton for the very first time, it will instantiate itself once.. and threads share memory stack/heap, so there's no way another thread will create another singleton in the same memory stack/heap..

what kind of multithreading environment are you using?

yes. it depends on how you code it. the explanations was discussed previously. The question is how do you code it with a high performance, lazy loaded in an multi-threaded environment. (Kindly refer our previous postings).

Consider this scenario:

thread A tries to get an instance
-- thread A checks if the instance is null, if null, then thread A instantiates it.

the another thread B tries to get an instance
-- thread B checks if the instance is null, by this time it's still null because thread A is not done instantiating-the-supposed-to-be single instance, then thread B instantiate the new instance. So there are two instance now.

[bluedes]

yes. it depends on how you code it. the explanations was discussed previously. The question is how do you code it with a high performance, lazy loaded in an multi-threaded environment. (Kindly refer our previous postings).

Consider this scenario:

thread A tries to get an instance
-- thread A checks if the instance is null, if null, then thread A instantiates it.

the another thread B tries to get an instance
-- thread B checks if the instance is null, by this time it's still null because thread A is not done instantiating-the-supposed-to-be single instance, then thread B instantiate the new instance. So there are two instance now.

i see.. race conditions.. locks are there for that purpose..

[kamsky]

i see.. race conditions.. locks are there for that purpose..

yes, race condition. Lock is the solution but how would you do it that you wont have any excessive locks, because you just need to lock it once and just once.

[bluedes]

yes, race condition. Lock is the solution but how would you do it that you wont have any excessive locks, because you just need to lock it once and just once.

then you just lock it once...

your thread B will check for a lock before locking it.. if a lock exists, it won't create a lock until that existing lock gets unlocked..

blocking mechanism is inherent in a lock.. you don't have to worry about this.. its the implementation's responsibility..