Design Pattern, Implementation Pattern and Best Practices

[cebugdev]

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.

to avoid excessive locking and since it is declared static create the instance of your singleton class BEFORE running any threads that will access the class.


void main()
{
MySingleTon::Initialize();

new Thread(fnThread1).Start();
new Thread(fnThread2).Start()
}

[kamsky]

to avoid excessive locking and since it is declared static create the instance of your singleton class BEFORE running any threads that will access the class.


void main()
{
MySingleTon::Initialize();

new Thread(fnThread1).Start();
new Thread(fnThread2).Start()
}

the problem really is:

Main() :
   Thread A:
      Singleton.init();

   Thread B:
      Singleton.init();

[kamsky]

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

From your statement it looks like your thread B will acquire lock again if the lock is release by thread A. Then they will acquire locks many times.

kindly refer to previous postings, the solutions is already there.

[bluedes]

From your statement it looks like your thread B will acquire lock again if the lock is release by thread A. Then they will acquire locks many times.

kindly refer to previous postings, the solutions is already there.

i see what you mean.. that is the use of locks.. di man pwede na once ra ka mugamit ug lock.. what's the use of locking if once ra nimo gamiton? so if you implement locking, it will always be in use all through out in other threads..

if you don't want to use locking, then instantiate the singleton in the parent process before any other thread gets hold of it.. this way, deterministic na imong algorithm..

[MarkCuering]

to avoid excessive locking and since it is declared static create the instance of your singleton class BEFORE running any threads that will access the class.

void main()
{
MySingleTon::Initialize();

new Thread(fnThread1).Start();
new Thread(fnThread2).Start()
}

bro, in JAVA, when we declare it as "static" it is already initialized at runtime... same also in C#.NET. that's why they declared the class constructor as "Private & Static". it means only at the runtime and strictly the CLR/JVM lang ang maka initialized.

Sounds threadsafe right? but believed me its not...especially if your class constructor are busy initializing other modules, or waiting/fetching some objects across the network

[MarkCuering]

i see what you mean.. that is the use of locks.. di man pwede na once ra ka mugamit ug lock.. what's the use of locking if once ra nimo gamiton? so if you implement locking, it will always be in use all through out in other threads..

pwede man na bro na one time lng use of lock, add lang ka ug condition if it requires locking.

if you don't want to use locking, then instantiate the singleton in the parent process before any other thread gets hold of it.. this way, deterministic na imong algorithm..

mau ni iyang problema which I believed he already have some solutions, coz it really depends upon the situation and implementation sa class, that implements singleton pattern.

[kamsky]

i see what you mean.. that is the use of locks.. di man pwede na once ra ka mugamit ug lock.. what's the use of locking if once ra nimo gamiton? so if you implement locking, it will always be in use all through out in other threads..

if you don't want to use locking, then instantiate the singleton in the parent process before any other thread gets hold of it.. this way, deterministic na imong algorithm..

locking has overhead. race condition is only happening once. so you only need to lock during race condition, which is in this case the instantiation of singleton. Once you have successfully created the instance successfully, you dont really need to lock again.

[MarkCuering]

Some Test that I made, a scnenario where two or more instances of singleton class may appear.

THE AMAZING RACE OF 100 THREADS TOWARDS THE MIGHTY SINGLETON!

*** FIRST ATTEMPT *** ( 2 DIFFERENT INSTANCE, 98 SAME)

T_0 is now initializing Singleton class
T_1 is now initializing Singleton class
T_0 Done...
This is T_0 - Singleton: 63835064
T_1 Done...
This is T_1 - Singleton: 6044116
T_2 Done...
This is T_2 - Singleton: 6044116
T_3 Done...
This is T_3 - Singleton: 6044116
.
.
.

This is T_99 - Singleton: 6044116
Press any key to continue . .

*** SECOND ATTEMPT *** ( 10 DIFFERENT INSTANCE, 80 SAME)

T_0 is now initializing Singleton class
T_1 is now initializing Singleton class
T_2 is now initializing Singleton class
T_3 is now initializing Singleton class
T_4 is now initializing Singleton class
T_5 is now initializing Singleton class
T_6 is now initializing Singleton class
T_7 is now initializing Singleton class
T_8 is now initializing Singleton class
T_9 is now initializing Singleton class
T_0 Done...
This is T_0 - Singleton: 63835064
T_1 Done...
This is T_1 - Singleton: 6044116
T_2 Done...
This is T_2 - Singleton: 4032828
T_3 Done...
This is T_3 - Singleton: 35320229
T_4 Done...
This is T_4 - Singleton: 12547953
T_5 Done...
This is T_5 - Singleton: 12036987
T_6 Done...
This is T_6 - Singleton: 62476613
T_7 Done...
This is T_7 - Singleton: 45653674
T_8 Done...
This is T_8 - Singleton: 39086322
T_9 Done...
This is T_9 - Singleton: 20974680
.
.

T_16 Done...
This is T_16 - Singleton: 20974680
T_17 Done...
This is T_17 - Singleton: 20974680
.
.
.
T_99 Done...
This is T_18 - Singleton: 20974680

MAIN CODE:

    public static void Main()
	{
        int MAX = 100;

        Thread[] MyThreads = new Thread[MAX];
        for (int i = 0; i < MAX; i++)
        {
            MyThreads[i] = new Thread(new ParameterizedThreadStart(TestSearch.TestSingleton));
            MyThreads[i].Name = "T_" + i.ToString();
        }
        for (int i = 0; i < MAX; i++) MyThreads[i].Start();
    }

TestSingleton Method

    public static void TestSingleton(object o)
    {
        Singleton s = Singleton.getInstance();

        if (!Singleton.IsDone)  Console.WriteLine("This is {0} - Singleton: {1}", Thread.CurrentThread.Name, s.GetHashCode());
        else Console.WriteLine("This is {0} - Singleton: {1}", Thread.CurrentThread.Name, s.GetHashCode());

    }

Singleton getInstance Method

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

            Console.WriteLine("{0} Done...", Thread.CurrentThread.Name);
            return MyInstance;
        }

Solution many to mentioned... some are yet to be discovered by kamsky

[eax]

How about synchrone the getInstance() method?

[kamsky]

How about synchrone the getInstance() method?

we have discussed that already. synchnorize has overhead. kindly read the previous post.