Research using Singleton Mode Under multithreading (original, good solution)

The Singleton mode with multiple threads has some disadvantages. But how can this problem be solved? The solution is to use the lock mechanism. The lock mechanism studied today, and by the way, I learned some about the CPU-level mechanism of multithreading.

In a single CPU environment, the CPU can only do one thing at a certain time of the system, with one slice, which is the minimum unit of CPU execution. Multiple processes in the system seem to be running at the same time, but in fact these processes are all in a queue and lined up. The CPU runs first in a time slice. Of course, when processing the first process, it is very likely that a time slice has passed, but this process is still incomplete, therefore, the CPU management mentions the last bit of the waiting queue, and uses a time slice to execute the next process. However, the time of a time slice is variable, basically in milliseconds, therefore, in the waiting queue of this process, it may be repeated in one second, that is, there has been execution, so it seems that every process is executing the same. There is a problem, that is, why does PCU finish executing a process not once? This eliminates the need for troublesome queue management issues. However, the mechanism of Windows is like this, ensuring fairness and having a priority principle. For example, it takes one second for your process to complete, however, it takes 10 seconds to complete the execution before you start, so the CPU allows you to jump into the queue.

Of course, there is also a sleep queue. When this thread is sleep, the system will add this thread to the sleep queue until your sleep time is reached and you will mention the last one waiting for the queue, wait for the CPU to come to you.

The lock mechanism (not sure whether it is unique to C #) is a resource lock guy. He can ensure that the lock is not completed in the statement block, and it will not release resources for other threads to access.

There are several lock methods. Lock (this) means to lock the entire object, or lock (typeof (a) (a is the class name of this class) can of course be implemented, but, to lock the entire object, other threads need to access this object, but it does not involve the lock statement. Therefore, they cannot obtain the locked resources (this) or the resources of the entire class. The best solution is to create an object created for the lock mechanism.

Below, I am writing a solution that I think is perfect for solving the singleton multithreading problem. It is a template in which the singleton error is amplified by using thread sleep.

Using system;
Using system. Threading;

Namespace Singleton
{
Class
{
Static readonly object padlock = new object ();
String S;
Private A (string X)
{
S = X;
}
Static A = NULL;
Public static A geta (string S)
{

Lock (padlock)
{
If (A = NULL)
{
Random RD = new random (unchecked (INT) datetime. Now. ticks ));
Int v = RD. Next (10,100 0 );
Thread. Sleep (v );
A = new A (s );
}
}
Return;
}
Public override string tostring ()
{
Return S;
}
 
}

Class B
{
A A = NULL;
Public void test1 ()
{
A = A. Geta ("Morning! ");
Console. writeline (A. tostring ());
}
Public void Test2 ()
{
A = A. Geta ("Afternoon! ");
Console. writeline (A. tostring ());
}
}
Class t
{
Static void main ()
{
B = new B ();
Thread T1 = new thread (New threadstart (B. test1 ));
Thread t2 = new thread (New threadstart (B. Test2 ));
T1.start ();
T2.start ();

 

}
}
}

I want this thread to sleep because I want it to hand over the time slice to other threads so that it can have the opportunity to implement multiple object errors in singleton mode.

In this case, if you don't lock and annotate the lock statement, multiple objects will be created in singleton mode!

Of course, there is also a small problem, that is, when using lock, the statements that can be unlocked as far as possible should be put out, do not put in the lock statement! The truth is obvious.