1
Threads, Events and Mutexes
Threads operate on the premise that the computer is definitely more expeditious than a human at executing tasks, resulting in the computer idling away most of its processing time, waiting for the human operator. Threads are a means of overcoming this wastage of processing time. They perform multiple tasks on a computer in rapid succession, thereby, creating the illusion of these tasks being executed simultaneously. No application can ever be comprehensive without employing threads. Before we try to infer what a thread does in the programming context, let us rummage through a few examples given below.
Without being discursive, let us venture out on our odyssey of understanding the concept of a thread with the assistance of a very diminutive program.
a.cs
using System.Threading;
public class yyy
{
public static void abc()
{
System.Console.WriteLine("Hi");
}
}
public class zzz
{
public static void Main()
{
ThreadStart ts = new ThreadStart(yyy.abc);
Thread t = new Thread(ts);
System.Console.WriteLine("Before Start");
t.Start();
}
}
Output
Before Start
Hi
This one is bound to leave you astonished because, we had earlier talked about starting out with a 'dimunitive' program. However, by no stretch of the imagination can the above program qualify as miniscule. Besides, the only work accomplished by this function is that it calls the static function abc, which in turn displays 'Hi'.
In Main, we create an object ts, which is an instance of the class ThreadStart, which is derived from Delegate. Therefore, even though ThreadStart is a class, it also happens to be a delegate, whose constructor is given a static function called abc. Function abc is placed in the yyy class so that other classes can also use it. The program will work in a similar manner even if the static function is placed in class zzz.
Next, we create another object t, which is an instance of Thread. The constructor of this object is given a ThreadStart object ts. Indirectly, ts stands for the static function yyy.abc since it is a delegate.
So far, tranquility prevails and nothing transpires. The function yyy.abc too does not get called. But, as soon as we call Start off the thread, the function abc gets catapulted into action. Thus, the function abc is called only when the Start function is called. This is really no big deal. Note that classes beginning with Thread belong to the System.Threading namespace.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("Hi");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
}
}
Output
Hi
The above program is similar to the previous one and resembles the samples supplied by Microsoft. The function abc to be called, is non-static and hence, an object name is needed to reference it. The ThreadStart delegate object is directly passed as a parameter to the Thread constructor.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3;i++)
{
System.Console.Write(i + " ");
}
}
public void pqr()
{
for ( int i = 0; i<=3;i++)
{
System.Console.Write(i+ "...");
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.pqr));
t.Start();
t1.Start();
}
}
Output
0 1 2 3 0...1...2...3...
The example embodies a very large amount of code. However, it does not create any fresh ripples in our pond of knowledge. We have merely created two Thread objects t and t1, and passed their constructors a different delegate or function name, i.e. abc and pqr, respectively. Thereafter, the Start function has been called in t and t1. Here, the function abc gets called, which displays four numbers. Thereafter, the function pqr gets called, which also displays four numbers, but with three dots.
You may wonder with trepidation as to when you will bite into the real meat. Keep your impatience in abeyance for a little while !
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3;i++)
{
System.Console.Write(i + " ");
Thread.Sleep(1);
}
}
public void pqr()
{
for ( int i = 0; i<=3;i++)
{
System.Console.Write(i+ "...");
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.pqr));
t.Start();
t1.Start();
}
}
Output
0 0...1 1...2 2...3 3...
Now, we are at the threshold of excitement. By adding the function Sleep, which is a static function in the Thread class, the functions abc and pqr get called simultaneously, although not sequentially. This is how the concept of a thread is implemented, i.e. it empowers your computer to accomplish multiple jobs at the same time. This process is also termed as multi-tasking.
Take the case of Microsoft Word. When you attempt to save a file, irrespective of the size of the file, Word appears to consume the same amount of time in completing this task. To expect it to save a 10MB file within a very short time period is a thought fraught with absurdity and contrary to reason. Actually, what the Word program does is that it creates a thread and then solicits the thread to save the file. While the thread is saving that file, another thread waits for the user to type something. Hence, the user is emancipated to continue working with Word. Thus, in effect, two tasks are being executed concurrently without the user being cognizant of it ! The same mechanism is employed by Excel and other similar products.
Any application under Windows runs in its own thread. Thus, if two programs are launched, there will be two threads running. The operating system refrains from playing favorites and gives an equal amount of time to each thread to execute. If there are two threads co-existing, then, out of every minute of processing time available, each of them will be allotted 30 seconds to execute. If a third program is now executed, a new thread will be launched and each of the three threads will be allotted only 20 seconds of the processor time per minute to execute.
If, instead of running a third program, what if the second program itself creates a thread ? As before, this will result in the creation of a third thread and each thread will be allotted 20 seconds of time. The resultant effect would be that that the first program will be allotted 20 seconds of time, whereas the second program will get 40 seconds per minute of the processor time. Thus, the larger number of threads that a program creates, more will be the processor time allotted to it. If you crave for more time and attention from your computer, desist from throwing a tantrum. Instead, generate greater number of threads.
The computer allots a specific amount of time to each thread and then puts it to sleep. Thereafter, it executes another thread. The time given to each thread to execute its code is designated as a Time Slice. This allocation of Time Slices occurs so swiftly that each thread suffers from the hallucination that it enjoys the undivided attention of the computer.
The static function Sleep in the Thread class facilitates this process. Sleep is like the sandman. It puts the thread to sleep for a certain number of milliseconds, as specified in its parameter. In this case, it is 1 millisecond. In the earlier example, in a single time slice, the Thread executed all the code and the function completed execution. In this case, the Sleep delays it long enough for the next thread to execute, and thus, the code in the functions get called one after the other.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3;i++)
{
Thread t2 = Thread.CurrentThread;
System.Console.Write(i + "." + t2.Name + " ");
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Name="One";
t1.Name="Two";
t.Start();
t1.Start();
}
}
Output
0.One 0.Two 1.One 1.Two 2.One 2.Two 3.One 3.Two
Here, we have provided mental catharsis by simplifying the program. What we actually have done is given the same function name abc to our delegate. We have also used the property Name of the Thread class to assign a distinct name to each thread, i.e. One and Two respectively. Under normal circumstances, the names assigned are pre-ordained by the system. Now, both the threads will call the same function abc. How do we determine as to which thread is calling the function abc?
The Thread class can have members, which are either static or instance. CurrentThread is a static read-only property that returns a thread object, which represents the thread that has currently called the function. Here, Thread t2 will either represent t or t1, and the property Name will display the name of the thread executing the function.
a.cs
using System.Threading;
public class zzz : Thread
{
}
Compiler Error
a.cs(2,14): error CS0509: 'zzz' : cannot inherit from sealed class 'System.Threading.Thread'
The Thread class is a sealed class, therefore we cannot derive from it. The designers of the Thread class at Microsoft have held very doctrinaire opinions, in that, they believe that they have envisaged all the possible features required in this class. Thus, they have not provided any facility to override or modify it. Therefore, we are constrained to use the Thread class exactly as provided, without introducing any code that will complement or add to or subtract from the code of the Thread class. For your information, the Thread class in turn is derived from the interface ISerializable.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("Hi");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
System.Console.WriteLine(t.IsAlive);
t.Start();
System.Console.WriteLine(t.IsAlive);
t.Abort();
System.Console.WriteLine(t.IsAlive);
}
}
Output
False
True
Hi
False
The Thread class has a property called IsAlive that reveals the current state of the Thread. When we create an object that looks like Thread, the thread is in a dead state and hence, the IsAlive property has a value of False. Start breathes life into the thread and executes through the delegate abc. The thread now comes alive, but the code in the thread function gets executed only after the subsequent WriteLine function, which displays the value of IsAlive as True. When we stop or Abort the Thread, the thread dies and the value of the property IsAlive reverts back to False. Thus, IsAlive can hold only one of the two values, False for dead or True for alive.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("Hi");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
while ( !t.IsAlive )
System.Console.WriteLine("hi1");
}
}
Output
Hi
In today's world, we are working on extremely fast machines. When we execute t.Start(), the thread is brought to life in a fraction of a second. Hence, the while loop is not executed because the condition becomes false immediately. Had the machine been slower, the while loop may have got called a few times, as it would have taken some time before the thread could have been brought to life. Thus, the speed of execution may vary, depending upon the speed of the machine. Whenever the sample code creates a thread, it always contains this while loop.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3 ; i++)
System.Console.Write("Hi " + i + " ");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
System.Console.WriteLine("Over");
}
}
Output
Over
Hi 0 Hi 1 Hi 2 Hi 3
The executable, a.exe, runs in its own thread. So, before calling the function Start, we already have one thread running. On calling the function Start, two threads run concurrently, independent of each other. The second thread executes the function abc independent of the first thread. The first thread executes the last WriteLine function and then stops, whereas the second thread continues executing the function abc till there is no more code to call. If, on your machine, the first thread's time slice gets over before executing the WriteLine function, then some code of the function abc may get executed before Over gets displayed in the function Main. It is reiterated yet again that, in case of threads, there can be no guarantee as to when the time slice of a thread will get over. Even the operating system is not sagacious enough to offer any guarantees in this regard.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3 ; i++)
System.Console.Write("Hi " + i + " ");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
t.Join();
System.Console.WriteLine("Over");
}
}
Output
Hi 0 Hi 1 Hi 2 Hi 3 Over
The function Join is a blocking function. It makes the program linger at the function Join till the thread finishes execution. Any code after the Join, in this case the WriteLine function, will be executed only after the thread dies. A blocking function will wait until the purpose it is waiting for has reached fructification. Thus, if we want to wait for a thread to complete execution, we use a Join. Join behaves like a party host, who is always the last to leave.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( ; ; ) ;
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
bool b = t.Join(10000);
System.Console.WriteLine("Over " + b);
}
}
Output
Over False
The Join function accepts a number as a parameter, which represents the maximum duration in milliseconds that it should wait for the thread to complete execution. In our example, the function abc will never end. Thus, the thread t will go on forever. Therefore, the Join function waits for 10 seconds, gives up and finally returns a False.
Therefore, we are empowered to decide the duration for which we want to wait for the thread to complete execution. Let us not forget that our application has not yet terminated and is still hanging around in memory. At this stage, if you press Ctrl-Alt-Del, you will see a list of programs running. Now, select the End Task option for the program called 'a'. An alternative approach could be to add the Abort function t.Abort() after the WriteLine function.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( ; ; ) ;
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Join();
}
}
Output
Unhandled Exception: System.Threading.ThreadStateException: Thread has not been started.
at System.Threading.Thread.Join()
at zzz.Main()
If there is no thread running, the Join function will throw the exception of ThreadStateException.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("abc");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
Thread.Sleep(3);
t.Abort();
System.Console.WriteLine("Over");
Thread.Sleep(100);
t.Start();
}
}
Output
abc
Over
Unhandled Exception: System.Threading.ThreadStateException: Thread is running or terminated. Cannot restart.
at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark & stackMark)
at System.Threading.Thread.Start()
at zzz.Main()
At first, we start the thread t by calling the Start function. Thereafter, we make the main thread sleep for a little while. Then, we abort the thread and again sleep for a little while, in order to enable the thread to fulfill its last wishes and finally die. Now that the thread is dead, we try and infuse life into it by calling Start again. A thread, which has died cannot be resuscitated. Since we have had the audacity to attempt this, the results are nearly cataclysmic, resulting in the generation of an exception which has to be caught.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("abc");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
Thread.Sleep(3);
t.Abort();
System.Console.WriteLine("Over");
Thread.Sleep(100);
try
{
t.Start();
}
catch (ThreadStateException e)
{
System.Console.WriteLine("In Exception");
}
}
}
Output
abc
Over
In Exception
The exception thrown is ThreadStateException, which needs to be caught in our code. Otherwise, the runtime message box is displayed to the user.
The Thread class constructor can throw two types of exceptions:-
• ArgumentNullException - When it is called without a delegate in the constructor.
• SecurityException - When the program does not have permission to create a thread.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("abc");
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
System.Console.WriteLine(t.ApartmentState);
t.ApartmentState = ApartmentState.STA;
t.Start();
System.Console.WriteLine(t.ApartmentState);
}
}
Output
Unknown
STA
abc
We all have our own apartments, which are normally done up as per our preferences i.e. 'We are the kings of our castles'. Threads also have apartments. Any thread can be asked to execute either in a single-threaded apartment or in a multi-threaded apartment. These values can be established using the property ApartmentState, either once at the beginning, or while the thread is running. The various values that ApartmentState can assume are as follows:
· STA : Single Threaded Apartment.
· MTA : Multi Threaded Apartment.
· Unknown : Default value assigned when no value is set.
We, however, cannot use numbers for a string. Thus, an enum called ApartmentState has been used. It holds three values i.e. 0, 1 and 2 corresponding to STA, MTA and Unknown respectively.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
System.Console.WriteLine("abc " + Thread.CurrentThread.IsBackground);
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
System.Console.WriteLine("Main " + Thread.CurrentThread.IsBackground);
t.Start();
}
}
Output
Main False
abc False
A thread executes either in the background or in the foreground. The property IsBackground indicates the mode in which the thread will run. An important point to be noted here is that, a thread which executes in the background automatically shuts down when its main program quits.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0 ; i<=100; i++)
{
System.Console.WriteLine("abc " + i);
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
System.Console.WriteLine("Main " + Thread.CurrentThread.IsBackground);
t.IsBackground = true;
t.Start();
Thread.Sleep(10);
}
}
Output (t.IsBackground = true)
Main False
abc 0
Output (t.IsBackground = false)
Main False
abc 0
abc 1
abc 2
..
..
abc 100
When you change the true to false in t.IsBackground, the output shows the code of function abc being executed. The for loop displays values from 0 to 100.
By changing the property IsBackground of a thread to true, the thread terminates when the main program stops. Thus, the for loop does not have the time to display values upto 100. At times, the program displays abc with a value of 0.
The sleeps are used to demonstrate the effect of the first thread shutting down and the second carrying on execution. On changing the property IsBackground to false, the thread takes its own sweet time to execute its code without any regard for the first thread, which may or may not have completed its job. So, the foreground threads behave exactly in the same manner as the background threads, when the property is initialized to true.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=10;i++)
{
System.Console.Write(i + " ");
Thread.Sleep(1);
}
}
public void pqr()
{
for ( int i = 0; i<=10;i++)
{
System.Console.Write(i+ "...");
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.pqr));
System.Console.WriteLine(t.Priority);
t.Priority = ThreadPriority.Highest;
t1.Priority = ThreadPriority.Lowest;
t.Start();
t1.Start();
}
}
Output
Normal
0 1 2 3 4 0...5 1...6 2...7 3...8 4...9 5...10 6...7...8...9...10...
We are at liberty to decide the duration of the time-slice to be allotted to our thread vis-a-vis other threads. This can be achieved by setting the Priority property accordingly. By default, the priority level is 2. Hence, we see 'Normal' displayed as the output. All threads start at this priority level. The ThreadPriority enum comprises of five levels of priority, which are as follows:
• 0 - Zero
• 1 - BelowNormal
• 2 - Normal
• 3 - AboveNormal
• 4 - Highest
In our program, we have changed the priority of thread t to the highest possible and that of thread t1 to the lowest. As a result, Thread t is accorded more time than thread t1, and it finishes its for loop much before thread t1 can do so.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
try
{
System.Console.WriteLine("in abc");
for ( ; ; ) ;
}
catch ( System.Exception e)
{
System.Console.WriteLine("in abc Exception " +e.ToString() );
}
finally
{
System.Console.WriteLine("in abc Finally");
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
Thread.Sleep(10);
t.Abort();
}
}
Output
in abc
in abc Exception System.Threading.ThreadAbortException: Thread was being aborted.
at yyy.abc()
in abc Finally
Aborting a Thread while it is busy executing some code generates an exception. Thus, the function abc will be sent an exception, resulting in a call to the 'catch' and 'finally' clauses. The thread will be terminated after executing the code in the Catch and the Finally clause.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
try
{
System.Console.WriteLine("in abc");
for ( ; ; ) ;
}
catch ( System.Exception e)
{
System.Console.WriteLine("in abc Exception " +e.ToString() );
}
finally
{
System.Console.WriteLine("in abc Finally");
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Abort();
t.Start();
}
}
Output
(no output)
Aborting a thread before it has started execution does not generate any exceptions, since the thread is in a dead state. Hence, no code in abc ever gets called. This situation is akin to the one where you don your best attire to watch cricket live at the stadium, but the show gets ruined due to heavy downpour, resulting in the match being abandoned without a ball being bowled !
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for (int i = 1 ; i<= 10 ; i++ )
{
System.Console.Write(i + " " );
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
Thread.Sleep(10);
t.Suspend();
System.Console.WriteLine("\n After Suspend");
Thread.Sleep(10);
System.Console.WriteLine("Before Resume");
t.Resume();
}
}
Output
1
After Suspend
Before Resume
2 3 4 5 6 7 8 9 10
We are allowed to Suspend a thread executing its code, at any point in time. In the above program, we let the thread run for a little while and then Suspend it. Thereafter, we Resume it. Thus, the thread is like a puppet in our hands. We can decide when and which strings to pull and the thread does our biding. If the thread has already been suspended, then Suspending it once again has no effect, and thus, it does not result in an error. A single Resume is enough to undo a million Suspends.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
for ( int i = 0; i<=3;i++)
{
Thread t2 = Thread.CurrentThread;
System.Console.Write(i + " " + t2.GetHashCode() + " ");
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
0 2 0 3 1 2 1 3 2 2 2 3 3 2 3 3
Every thread is assigned a number internally. This number is called the HashCode. Hashing is the process of assigning a number to an entity so that it can easily be located from a long list. This hash number is useful and is pressed into service when we are required to keep track of a large number of threads internally.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
Monitor.Enter(this);
for ( int i = 1; i<=5;i++)
{
System.Console.Write(i + " " + Thread.CurrentThread.GetHashCode() + " ");
Thread.Sleep(1000);
}
Monitor.Exit(this);
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
1 2 2 2 3 2 4 2 5 2 1 3 2 3 3 3 4 3 5 3
Let us now clarify the abstract concept of the life of a thread with the help of an example.
Any resource that many people desire is called a shared resource. Imagine the chaos that would be caused if five programs tried to simultaneously use a single network printer for printing, during their respectively time-slices. This would result in the printer printing a few pages for program 1, then a few pages for program 2, and so on. The printer will keep printing merrily, but the printed output will all be jumbled up.
Thus, ideally, one program should use a shared resource at a time, till its job is complete. For this, a method has to be implemented by means of which, unless one program finishes executing some specific code in a function, no other program should be allowed to execute it. Thus, all other programs would have to wait until the first thread finishes execution.
Let us assume that function abc contains code which sends a request to the printer to print. The thread t gets the first shot at running abc. The second thread t1 has to wait until thread t finishes execution, even if the duration of executing abc takes more time than one time slice, due to a large value being assigned as a parameter to the sleep function. This is achieved by using the static function Enter of the class Monitor.
The function Enter is given an object which refers to the class in which the function resides. From that point onwards, every thread has to wait at Enter. The barrier lowers only when Exit is called from the Monitor class. Enter acts as a fussy security guard who decides as to which thread is to be prohibited and which one is to be permitted to execute code. No two threads can ever enter the Enter function together. It is a rigid one way lane from Enter to Exit. One car is allowed in at one time and another car can pass through only after the first car leaves Exit. You can see that the names Enter and Exit have been chosen very aptly.
a.cs
using System;
using System.Threading;
public class ggg
{
};
public class yyy
{
public ggg g1;
public void abc( )
{
Monitor.Enter(g1);
for ( int i = 1; i <= 3; i++)
{
Console.Write(" Hell " + i);
Monitor.Wait(g1);
Console.Write(" Waitabc " + i);
Monitor.Pulse(g1);
}
Monitor.Exit(g1);
}
};
public class xxx
{
public ggg g1;
public void pqr( )
{
Monitor.Enter(g1);
for ( int i = 1; i <= 3; i++)
{
Console.WriteLine(" Everyone " + i);
Monitor.Pulse(g1);
Monitor.Wait(g1);
Console.Write(" Waitpqr " + i);
}
Monitor.Exit(g1);
}
};
public class zzz
{
public static void Main(String[] args)
{
ggg g = new ggg( );
yyy a = new yyy( );
a.g1 = g;
Thread t = new Thread(new ThreadStart(a.abc));
t.Start( );
xxx b = new xxx();
b.g1 = g;
Thread t1 = new Thread(new ThreadStart(b.pqr));
t1.Start( );
}
};
Output
Hell 1 Everyone 1
Waitabc 1 Hell 2 Waitpqr 1 Everyone 2
Waitabc 2 Hell 3 Waitpqr 2 Everyone 3
cs Waitabc 3 Waitpqr 3
The above example may be a protracted one, yet it is fascinating.
The world has never been able to work with each other. The only global body we have is the UNO. People are mostly loners.
In the entry point function Main, we create an object g, which is an instance of a class ggg, having no code or variable. It embodies the emptiness of space. This is a class that is incapable of doing any good or bad. We then create two objects that look like yyy and xxx respectively, and pass them as delegates, so that the threads can call functions abc and pqr. We also initialize the object g1, an instance of ggg, in each of them to g. This is crucial. The g1's in yyy and xxx represent the same g that is created in Main.
After initializing the requisite members, we activate the two threads. As earlier, let us assume that the function abc gets called first.
Monitor.Enter considers taking a handle to any object, which is to be synchronized between multiple instances of threads, as its first parameter. This function needs an Exit function to release its handle. Thus, the number of Exits in the program must correspond to the number of Enters.
It prints "Hell", and then due to the Wait function, it waits indefinitely, till it finally receives runtime notification. However, the thread accomplishes nothing significant. Thus, we do not see the Waitabc displayed, since it is entered after the Wait function.
The second thread starts executing the function pqr. Monitor.Enter uses the same synchronized object, and now it displays Everyone. The next function to be called in pqr is Monitor.Pulse. Pulse does a very simple thing. It wakes up any thread having the same handle, which happens to be waiting at a Wait. Thus, the thread in abc wakes up. However, the one in pqr waits for someone to Pulse it.
By using Wait and Pulse, we can easily play a game of tag. The thread t performs some work and waits for thread t1 to wrap up whatever work it is preoccupied with. Thread t does not know how long thread t1 will take to fulfill its side of the bargain. But no sweat! Thread t waits at a Wait for the thread t1 to Pulse it. Then, thread t1 waits at a Wait for thread t to do some work. When thread t concludes, it Pulses thread t1, and so on. This can go on and may involve some other threads too.
The threads use the handle g, which is the synchronized region. It is akin to being an integral part of a clandestine social group. The parameter to these Monitor functions clubs them together as a group. If you change the handle, the group breaks up, leaving your thread in a lurch. The Wait function can also be made to wait for a specified time period.
If we change the line Monitor.Wait(g1) to Monitor.Wait(g1,0), the output changes dramatically.
A monitor is associated with an object on demand and it cannot be instantiated at all. If the constructor is private, we can never create an object. But, the static functions of that object can be used. The Monitor functions can be called from anywhere since they are unbound. There are no restrictions on the sources of the object to be called.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
Monitor.Enter(this);
Monitor.Enter(this);
for ( int i = 1; i<=3;i++)
{
System.Console.WriteLine(i + " " + Thread.CurrentThread.GetHashCode() + " ");
}
Monitor.Exit(this);
}
}
public class zzz
{
public static void Main() {
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
1 2
2 2
3 2
The Exit function can be called as often as one desires. In this program, we have two threads, t and t1. Let us assume that thread t has the first go. At this time, it will pass through the first Monitor.Enter, as well as the second Monitor.Enter, without waiting at all. However, thread t1 will have to wait at the first Monitor.Enter, since the thread t called the Enter function twice, but Exited only once. Thus, the program never quits out. Had it called Exit twice, the thread t1 too would have woken up.
a.cs
using System.Threading;
public class yyy {
public int j=1;
public void abc()
{
Monitor.Enter(j);
for ( int i = 1; i<=3;i++)
{
System.Console.WriteLine(i + " " + Thread.CurrentThread.GetHashCode() + " ");
}
Monitor.Exit(j);
}
}
public class zzz
{
public static void Main() {
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
t.Start();
}
}
Output
1 2
2 2
3 2
Unhandled Exception: System.Threading.SynchronizationLockException: Exception of type System.Threading.SynchronizationLockException was thrown.
at yyy.abc()
Monitor.Enter takes an object, and not a variable, as a parameter. This is the reason why we used this parameter or some reference object, in the earlier programs. If a variable or a value object is used, an exception will be thrown. Thus, value types or null objects are not allowed as parameters to Monitor.Enter.
a.cs
using System.Threading;
public class xxx
{
}
public class ttt
{
}
public class yyy
{
static int p = 1;
xxx x = new xxx();
ttt t = new ttt();
public void abc()
{
if ( p == 1)
{
Monitor.Enter(x);
p++;
}
else
Monitor.Enter(t);
for ( int i = 1; i<=3;i++)
{
Thread.Sleep(1000);
System.Console.WriteLine(i + " " + Thread.CurrentThread.GetHashCode() + " ");
}
Monitor.Exit(x);
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
1 2
1 3
2 2
2 3
3 2
3 3
The Enter function must be used with some caution. The variable p initially has a value of 1. The first thread t sees the value of p as 1. Hence, the 'if' statement is true. Thus, it crosses Monitor.Enter with x as a parameter. It then takes a snooze at the Sleep function, while the second thread t1 executes function abc, where it sees the value of variable p as 2. This thread now meets the Monitor.Enter function, with t as the parameter. The object reference given to this Enter is entirely at variance with the object given to the earlier one. Thus, both the threads execute the Enter function, which fails the very objective of the Enter function. For Enter to work as expected, it should be provided with the same object as a parameter to itself.
The concept of a Lock is normally used to explain the Monitor class. One thread gets a Lock, while the others wait until the lock is released.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
bool b = Monitor.TryEnter(this);
System.Console.WriteLine(b);
for ( int i = 1; i<=3;i++)
{
Thread.Sleep(1000);
System.Console.WriteLine(i + " " + Thread.CurrentThread.GetHashCode() + " ");
}
Monitor.Exit(this);
}
}
public class zzz
{
public static void Main() {
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
True
False
1 2
1 3
2 2
2 3
3 2
3 3
The TryEnter function is similar to the Enter function, but it does not block. If the thread enters successfully, TryEnter returns a true. This is what happens the first time. But in the case of the second thread t, it returns a false, even when it enters the critical section.
a.cs
using System.Threading;
public class yyy
{
public void abc()
{
bool b = Monitor.TryEnter(this,1000);
System.Console.WriteLine(b);
for ( int i = 1; i<=3;i++)
{
Thread.Sleep(1000);
System.Console.WriteLine(i + " " + Thread.CurrentThread.GetHashCode() + " ");
}
Monitor.Exit(this);
}
}
public class zzz
{
public static void Main()
{
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Start();
t1.Start();
}
}
Output
True
False
1 2
1 3
2 2
2 3
3 2
3 3
The TryEnter function is overloaded to accept a number as a parameter, which represents the time duration for which the TryEnter function should block or wait. In our case, the timeout exceeds the time that thread t spends in the function. Hence, we get a value of False. If we add an extra zero to the time parameter, it will return a true instead. If the value of the parameter is infinite, the behaviour of the TryEnter becomes akin to that of Enter.
Thread Attributes
a.cs
using System.Threading;
public class yyy
{
[System.ThreadStaticAttribute ()]
public static int j = 1;
public static int k = 1;
public void abc()
{
for ( int i = 1; i<=3;i++)
{
Thread t2 = Thread.CurrentThread;
j++;k++;
System.Console.Write(i + "." + t2.Name + " j=" + j + " k=" + k + " ");
Thread.Sleep(1);
}
}
}
public class zzz
{
public static void Main() {
yyy a = new yyy();
Thread t = new Thread(new ThreadStart(a.abc));
Thread t1 = new Thread(new ThreadStart(a.abc));
t.Name="One";
t1.Name="Two";
t.Start();
t1.Start();
}
}
Output
1.One j=1 k=2 1.Two j=1 k=3 2.One j=2 k=4 2.Two j=2 k=5 3.One j=3 k=6 3.Two j=3 k=7
A static variable is a loner, as reiterated by us on numerous occasions. It belongs to the class and not to an object. Thus, there will always be a single static variable.
Let us consider a case where we have two threads t and t1 executing code in the same function abc, that also contains static variables j and k. The first question that strikes us is 'Will each of the threads see the same static variable or a different one?' Also, if we assume that both threads cater to the same static variable, when one thread increments the variable, will the other thread see the new value? And if not, then, is the compiler creating a separate static variable for each thread?
Too many questions that need answers!
We want to possess the best of both the worlds. At times, we need the threads to work on the same static variable, while at other times, we need the threads to access separate copies of the static variable. The default behaviour is that of the static variable being shared. Thus, the variable k is incremented by both the threads, and each thread sees the same value. The value of k finally reaches 7 at the end.
The variable j has an attribute ThreadStaticAttribute above it. This attribute may have a fancy name, but it merely creates a separate variable for each thread executing the function. Thus, we have two static variables j, one for each thread t and t1. Any changes made to the value of the variable j by t, does not get reflected in the static variable j of the thread t1.
1.One j=2 k=2 1.Two j=3 k=3 2.Two j=4 k=4 2.One j=5 k=5 3.Two j=6 k=6 3.One j=7 k=7
The above attribute only acts on static variables. We see the above output when we remove static from the variables j and k. The compiler is very clear. The attribute ThreadStaticAttribute is only to be used on static variables, but when applied on non-static variables, the compiler does not generate any error or warning. It simply ignores the attribute. Thus, instance variables are shared across threads, whereas, local variables like i are independent of threads. Thus, a variable can either be shared across threads or may be independent of the thread. No in-between options are allowed.
Events
a.cs
using System.Threading;
public class zzz
{
public static void Main() {
ManualResetEvent a;
a = new ManualResetEvent(false) ;
System.Console.WriteLine("Before WaitOne " );
bool b = a.WaitOne(1000,false);
System.Console.WriteLine("After WaitOne " + b);
}
}
Output
Before WaitOne
After WaitOne False
We have created an object a that is an instance of a ManualResetEvent class. The constructor is assigned a value of false. Then, we call a function WaitOne from this class with a number as the first parameter, and a boolean value as the second parameter. This number, 1000, is the number of milliseconds for which we want the thread to wait at the function WaitOne. The thread therefore waits for one second before quitting out, and then returns a False. Had we used the enum Timeout.Infinite that has a value of -1, we could have made the function wait forever. Thus, we can keep a thread waiting either for a specified duration of time or forever.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a;
a = new ManualResetEvent(true) ;
System.Console.WriteLine("Before WaitOne " );
bool b = a.WaitOne(1000,false);
System.Console.WriteLine("After WaitOne " + b);
}
}
Output
Before WaitOne
After WaitOne True
By changing the value in the constructor to true, the thread just refuses to wait for anyone. It just whizzes past, without even acknowledging the presence of the function WaitOne. Further, the return value of WaitOne i.e. b returns a True.
Let us delve a little deeper into this mystery. A ManualResetEvent is like a boolean variable. It can possess only one of the two values, true or false. When we first created such an object, we gave it a value of false. So, the function WaitOne waited till the Event object turned into True or the time value expired. Since the time duration got over while waiting, and the value of the Event object was not set to True, it stopped blocking and returned with a value of false.
In the next example, the event object already has a value true and hence, there is no wait. Here, the function WaitOne returns true because the non-blocking in this case, cannot be attributed to a timeout. Thus, a ManualResetEvent has two states, true or false; or in technical lingo, signaled or non-signaled. A value of true implies a signaled state, while a false would mean that it is in the non-signaled state.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a;
a = new ManualResetEvent(true) ;
System.Console.WriteLine("Before WaitOne " );
bool b = a.WaitOne(1000,true);
System.Console.WriteLine("After WaitOne " + b);
b = a.WaitOne(10000,true);
System.Console.WriteLine("After second WaitOne " + b);
}
}
Output
Before WaitOne
After WaitOne True
After second WaitOne True
Since we do not consider ourselves to be very cerebral, we shall desist from using fancy terminology like signaled or non-signaled. Instead, we shall stick to the simple true and false. We initially created the object a to be true or signaled (Oops! There we go again!). It then passed the first and the second WaitOne without waiting. This occurred because it is a Manual ResetEvent (as the name itself suggests), and not automatic. Once it is set to true, the event cannot change to false automatically. This has to be accomplished manually.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a;
a = new ManualResetEvent(true) ;
System.Console.WriteLine("Before WaitOne " );
bool b = a.WaitOne(1000,true);
System.Console.WriteLine("After WaitOne " + b);
a.Reset();
b = a.WaitOne(10000,true);
System.Console.WriteLine("After second WaitOne " + b);
}
}
Output
Before WaitOne
After WaitOne True
After second WaitOne False
The Reset function can be used to change the state from true to false as it changes the state to false. Hence, it has to wait in queue like a commoner, since the event ignores the earlier WaitOne. After some time, it gets activated due to a timeout and the function WaitOne returns a False.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a;
a = new ManualResetEvent(false) ;
System.Console.WriteLine("Before WaitOne " );
a.Set();
bool b = a.WaitOne(1000,true);
System.Console.WriteLine("After WaitOne " + b);
b = a.WaitOne(10000,true);
System.Console.WriteLine("After second WaitOne " + b);
}
}
Output
Before WaitOne
After WaitOne True
After second WaitOne True
Now, despite the fact that that the Event is originally false or non-signaled, the Set function sets it to true or the signaled state. At this stage, no power on earth is equipped to stop the event as it surges past the WaitOnes, treating them with disdain. It is not in the least concerned about stopping-by to pay homage to them. Such arrogance !
The class ManualResetEvent is a sealed class, like most other classes belonging to the Thread family. The developers at Microsoft were of the belief that no one would be able to add any more value to the class, and thus forbade any changes. This class is also derived from another class called WaitHandle, which in fact, embodies functions like WaitOne etc. The constructor has to be passed a parameter that affirms the initial state of the Event object. No default state is available. The Set and Reset methods return a boolean value, which indicates whether the change has taken place successfully or otherwise.
WaitHandle is a class from which ManualResetEvent is derived. A class that offers functions which are polite, is called a synchronization class. People who are polite, wait for others to finish doing their work, and it is only then that they proceed with their own work. Any class that waits for another is called a synchronization class. All synchronization objects derive from WaitHandle, and so does ManualResetEvent.
We are cautioned not to use this class directly, since it is the other classes that use this class. The documentation very clearly specifies that the CLR i.e. the Common Language Runtime or code written by Microsoft, calls the constructor of WaitHandle. Therefore, do not use this class directly. You are being forewarned!
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a,b;
a = new ManualResetEvent(false) ;
b = new ManualResetEvent(true) ;
WaitHandle [] w = new WaitHandle[2];
w[0] = a; w[1] = b;
System.Console.WriteLine("Before WaitAll " );
bool c = WaitHandle.WaitAll(w,10000,true);
System.Console.WriteLine("After WaitAll " + c);
}
}
Output
Before WaitAll
After WaitAll False
We can complicate life as much as we like. Similarly, we can complicate the WaitOne, by introducing its elder brother, WaitAll. This function will wait for all the event objects to become true or signaled, or it will stay there till the timeout occurs. In this manner, life can be made as complicated as we like. Until all the events reach the signaled state, the WaitAll remains extremely stubborn and does not budge from its vantage position. It does not take cognizance if a few of the events are signaled. All the events should be signaled. This could be a number approaching infinity.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a,b;
a = new ManualResetEvent(false) ;
b = new ManualResetEvent(true) ;
WaitHandle [] w = new WaitHandle[2];
w[0] = a; w[1] = b;
System.Console.WriteLine("Before WaitAll " );
bool c = WaitHandle.WaitAll(w);
System.Console.WriteLine("After WaitAll " + c);
}
}
Output
Before WaitAll
The number of functions in the class WaitHandle may be numerous, but most of them are only helper functions, which make life tranquil. The WaitAll function, if called with a single parameter, assumes that the second parameter is Timeout.Infinite or -1. These overloads can be ignored safely. It is the same for the WaitOne method.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a,b;
a = new ManualResetEvent(false) ;
b = new ManualResetEvent(true) ;
WaitHandle [] w = new WaitHandle[2];
w[0] = a; w[1] = a;
System.Console.WriteLine("Before WaitAll " );
bool c = WaitHandle.WaitAll(w);
System.Console.WriteLine("After WaitAll " + c);
}
}
Output
Before WaitAll
Unhandled Exception: System.DuplicateWaitObjectException: Exception of type System.DuplicateWaitObjectException was thrown.
at System.Threading.WaitHandle.WaitMultiple(WaitHandle[] waitHandles, Int32 millisecondsTimeout, Boolean exitContext, Boolean WaitAll)
at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles, Int32 millisecondsTimeout, Boolean exitContext)
at System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles)
at zzz.Main()
The CLR (Common Language Runtime, if you have forgotten) never sleeps, but the compiler can be caught dozing at times. C# hates duplicates, and thus, we cannot pass the same handle to the WaitHandle array. If you attempt to do so, a runtime exception will be thrown even when there was no reason to throw an exception. The runtime could have simply ignored the duplicate, but it chose not to.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
ManualResetEvent a,b;
a = new ManualResetEvent(false) ;
b = new ManualResetEvent(true) ;
WaitHandle [] w = new WaitHandle[2];
w[0] = b; w[1] = a;
System.Console.WriteLine("Before WaitAll " );
int c = WaitHandle.WaitAny(w);
System.Console.WriteLine("After WaitAll " + c);
}
}
Output
Before WaitAll
After WaitAll 0
Change line containing w[0] = b; w[1] = a; to w[0] = a; w[1] = b; and the output changes to the following:-
Output
Before WaitAll
After WaitAll 1
The WaitAny function waits till any of the events change to signaled or true. When this occurs, it returns the array index of the event which caused the exit. In this case, object b is in the signaled state, and since it is the first member of the array, the return value is 0. On interchanging the object to b, which is the second array member, the return value becomes 1. If both events are in the signaled state, then the lower array index is returned. If a timeout occurs, the value returned is 258.
AutoResetEvent Class
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
AutoResetEvent a;
a = new AutoResetEvent(false) ;
System.Console.WriteLine("Before WaitAll " );
bool c = a.WaitOne(1000,true);
System.Console.WriteLine("After WaitOne " + c);
}
}
Output
Before WaitAll
After WaitOne False
Let us now move up the value chain. The AutoResetEvent class works in the same way like a ManualResetEvent class in the above example. It simply waits for the timeout to take place or the Event to be signaled.
a.cs
using System.Threading;
public class zzz
{
public static void Main() {
AutoResetEvent a;
a = new AutoResetEvent(true) ;
System.Console.WriteLine("Before WaitAll " );
bool c = a.WaitOne(1000,true);
System.Console.WriteLine("After WaitOne " + c);
c = a.WaitOne(10000,true);
System.Console.WriteLine("After WaitOne1 " + c);
}
}
Output
Before WaitAll
After WaitOne True
After WaitOne1 False
Ah! Again the wait. The AutoResetEvent object safely crosses the first WaitOne. But there is one major variation now in that, the state of the object changes from true to false or signaled to non-signaled. Thus, it is obliged to pay homage for some time at the second Wait. The name here is Auto and not Manual. Just as we would change color if we saw a wild boar charging at us, the AutoResetEvent changes state at the Wait. Everything else remains identical.
Mutexes
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main()
{
m = new Mutex(true,"vijay");
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
}
public void abc( )
{
System.Console.WriteLine("abc start");
m.WaitOne( );
System.Console.WriteLine("abc end");
}
}
Output
abc start
If the boolean value of true in the Mutex constructor is changed to false, the output will change to the following:-
Output
abc start
abc end
A mutex is a synchronization object derived from the class WaitHandle. A Mutex is, in some sense, similar to the other Event classes.
We commence by creating a mutex and assigning it a boolean value of either true or false. In this context, these values have a slightly different connotation. They decide whether the creating thread owns the object or not. True allows the thread to own it, whereas False does not. Thus, with a mutex, we need to become very materialistic and start taking ownership of things. The current thread owns the mutex while the other threads are inclined to own it.
True or false, signaled or non-signaled, own it or not, are all the same concepts. The main thread already owns the mutex, which is named as vijay. The name is optional and is used mostly to refer to the mutex. Thereafter, we create a thread which calls the function abc. After displaying a message, the function WaitOne is called. This function will now stake a claim for ownership of the mutex, but since the main thread owns it, thread t cannot proceed beyond this function until the original thread gives up ownership. If we change the True in the constructor to False, then the ownership is not claimed. Thus, the thread t will not have to wait at the WaitOne as there is no owner.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main()
{
m = new Mutex(true,"vijay");
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
}
public void abc( )
{
System.Console.WriteLine("abc start");
m.ReleaseMutex();
m.WaitOne( );
System.Console.WriteLine("abc end");
}
}
Output
abc start
Unhandled Exception: System.ApplicationException: Attempt to release mutex not owned by caller.
at System.Threading.Mutex.ReleaseMutexNative(IntPtr handle)
at System.Threading.Mutex.ReleaseMutex()
at zzz.abc()
The main thread becomes the owner of the mutex as the boolean value supplied in the mutex constructor is True. Then, in the function abc, we try to release the ownership of the mutex by using the function ReleaseMutex. The thread t does not own the mutex. Hence, we get a runtime error as only the owner i.e. the main thread, can release the ownership of a mutex and pass it on to another thread.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main() {
m = new Mutex(true,"vijay");
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
System.Console.WriteLine("Before Thread Sleep");
Thread.Sleep(10000);
System.Console.WriteLine("After Thread Sleep");
m.ReleaseMutex();
System.Console.WriteLine("All over");
}
public void abc( )
{
System.Console.WriteLine("abc start");
m.WaitOne( );
System.Console.WriteLine("abc end");
}
}
Output
Before Thread Sleep
abc start
After Thread Sleep
abc end
All over
Now alls well that ends well. The main thread sleeps for a little while and then calls ReleaseMutex. This awakens the thread t, and thus, the function abc now quits out. Remember that you cannot give away what you do not own.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main()
{
m = new Mutex(true,"vijay");
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
System.Console.WriteLine("Before Thread Sleep");
Thread.Sleep(1000);
System.Console.WriteLine("After Thread Sleep");
m.ReleaseMutex();
System.Console.WriteLine("Before WaitOne");
m.WaitOne();
System.Console.WriteLine("All over");
}
public void abc( )
{
System.Console.WriteLine("abc start");
m.WaitOne();
System.Console.WriteLine("abc before sleep");
Thread.Sleep(100000);
System.Console.WriteLine("abc end");
}
}
Output
Before Thread Sleep
abc start
After Thread Sleep
abc before sleep
Before WaitOne
There is a long sleep in the function abc. The mutex is still owned by the thread t, while the main thread is trying to regain its ownership. It can only gain ownership if the thread t releases the mutex or dies. Thus, until the thread t dies, we will not see All Over displayed at all. We could have had another sleep in abc and we could have released the mutex before that sleep. The choice is ours. Thus, a mutex is fully concerned with ownership issues. Either you own a mutex or you do not.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
static Mutex n;
public static void Main()
{
m = new Mutex(true,"vijay");
n = new Mutex(true);
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
System.Console.WriteLine("All over");
}
public void abc( )
{
System.Console.WriteLine("abc start");
Mutex [] g = new Mutex[2];
g[0] = m;g[1] = n;
Mutex.WaitAll(g);
System.Console.WriteLine("abc end");
}
}
Output
All over
abc start
The program will hang. This is because we have two mutexses that have to be waited upon. Both m and n fill up the array g, and since both are true, the function abc will wait forever. Same rules of event classes apply to a mutex object.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main()
{
m = new Mutex(true,"vijay");
zzz a=new zzz( );
Thread t= new Thread(new ThreadStart(a.abc));
t.Start();
System.Console.WriteLine("Before Thread Sleep");
Thread.Sleep(1000);
System.Console.WriteLine("After Thread Sleep");
m.ReleaseMutex();
System.Console.WriteLine("Before WaitOne");
m.WaitOne();
System.Console.WriteLine("All over");
}
public void abc( )
{
System.Console.WriteLine("abc start");
m.WaitOne();
System.Console.WriteLine("abc after Wait");
m.WaitOne();
System.Console.WriteLine("abc after second Wait");
Thread.Sleep(10000);
System.Console.WriteLine("End");
}
}
Output
Before Thread Sleep
abc start
After Thread Sleep
abc after Wait
abc after second Wait
Before WaitOne
End
All over
The same rules about mutex ownership as mentioned earlier are discussed here. There may be two WaitOne functions, but the first WaitOne that gets the ownership, retains it. Thus, there was no wait between the first and the second wait. The concept of a mutex is extremely simple. A particular thread owns it. It can cross a wait without waiting and only when it releases the mutex can another thread claim and possess its ownership. Other threads cannot own it and they will have to wait at a wait. Dual ownership is not allowed.
a.cs
using System.Threading;
public class zzz
{
static Mutex m;
public static void Main()
{
m = new Mutex(false,"vijay");
zzz a=new zzz( );
System.Console.WriteLine("abc start");
m.WaitOne( );
System.Console.WriteLine("abc end");
}
}
Output
abc start
abc end
A Mutex only works with multiple threads. So, using a mutex with a single thread is futile, because a mutex is concerned with determining as to which thread owns it. Therefore, there must be at least two threads.
Timers
a.cs
using System.Threading;
public class zzz
{
public static void Main() {
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100,0);
Thread.Sleep(1000);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
hell
Timers are time-related. We have created a timer object and have passed it 4 values in its constructor. The first parameter is the delegate object which represents the function that should be called after a certain interval elapses. The second parameter is the object to be passed to the timer function. The third and fourth parameters are numbers representing time i.e. time and period. If the thread is not asked to sleep, the main thread will quit out and there will be no thread running. The entire program will halt and all the unfired timers will die.
Thus, if we remove the last Sleep, the word 'hell' does not get displayed. The timer delegate has to receive an object as a parameter since it is part of the delegate signature. The timer also has to wait for a specified time which is stated in the constructor, before it can call the function. This wait is accomplished using a thread in a thread pool. Needless to say, the Timer class is a sealed class.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100,0);
t.Dispose();
Thread.Sleep(1000);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
(none)
If we ever desire to cancel the timer for whatever reasons, we can call the Dispose method to kill the timer. The timer dies and the function to be called does not get called at all.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
ManualResetEvent e = new ManualResetEvent(false);
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,10000,300);
t.Dispose(e);
e.WaitOne();
System.Console.WriteLine("All Over");
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
All Over
The Dispose function can also take a parameter which is an event that gets signaled when the timer dies. Thus, the program that would have waited indefinitely now quits out because, removing the timer from the timer queue instantly signals an event.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100,1);
Thread.Sleep(500);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
hell
hell
hell
hell
and so on
The third parameter to the timer constructor is the duration in milliseconds after which the timer should be fired. The second number can be either a 0 or any other number. Zero means the timer fires once and any other number signifies it as a periodic timer. This periodic timer keeps executing the function abc every 100 milliseconds, until told to do otherwise.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100,1);
Thread.Sleep(115);
t.Change(100,0);
Thread.Sleep(1300);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
hell
hell
hell
The Change function is used to stop a periodic timer. Thus, the timer can be made to run for some time in a periodic manner and thereafter, the Change can be used to stop it from executing repeatedly.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100000,1);
Thread.Sleep(115);
t.Change(100,0);
Thread.Sleep(1300);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
hell
The timer initially is set to go off after a very long time. We let the main thread sleep for a little while but then change the due time of the timer to a smaller value. Thus, we can use the Change function to alter the initial settings of the timer.
a.cs
using System.Threading;
public class zzz
{
public static void Main()
{
zzz a = new zzz();
a.pqr();
}
public void pqr()
{
Timer t;
yyy b = new yyy();
t = new Timer(new TimerCallback(b.abc),this,100,300);
Thread.Sleep(1000);
}
}
public class yyy
{
public void abc(object o)
{
System.Console.WriteLine("hell");
}
}
Output
hell
hell
hell
Our dictum has always been to understand things one step at a time. The last parameter to the timer constructor can either be zero or any other value. If the value is 100, it means that every hundred seconds the timer will go off, until it is stopped by a Change or a Dispose. Earlier, we had used the number 1 to signify that the timer should be called every 1 second. You are free to decide these timer values depending upon what you intend to use the timer for. The values cannot be negative and cannot exceed 4294967294 either. If you do so, an exception will occur. Exceptions, lest you have forgotten, are generated at runtime only.
Thread Pool
a.cs
using System;
using System.Threading;
public class yyy {
public ManualResetEvent a = new ManualResetEvent(false);
public void abc(Object s)
{
a.WaitOne(10,true);
Console.WriteLine("{0} ", Thread.CurrentThread.GetHashCode());
}
};
public class zzz {
public static void Main() {
ManualResetEvent b = new ManualResetEvent(false);
yyy y = new yyy();
for (int i=1;i<=5;i++)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(y.abc),1);
}
b.WaitOne(10000,true);
}
}
Output
2
2
2
2
2
The rationale of a thread pool is that the decision makers at Microsoft did not want us to spend time taking care of threads like mothers take care of babies.
We will first explain the above program and then delve into the nitty-gritty of thread pools. Since we are lazy, we use a for statement to avoid repeating the same code over and over again. The function QueueUserWorkItem will be called at least five times because it is placed in this for loop.
QueueUserWorkItem function requires one, or at the most, two parameters. The first parameter, which is the name of a function, is most crucial. The name is never ever assigned directly, but indirectly, using a WaitCallback object. The function to be called is y.abc. Hence, it is passed a parameter to WaitCallback. The second parameter to the function QueueUserWorkItem is the number 1. As a result, the function abc has to accept a parameter of type object which will contain the value 1. A parameter of type object does not have any useful code and by itself is totally useless.
Every entity in C# is finally derived from the object class. Thus, every entity is of an object type. Whenever we are not aware of the parameter type to be received in a function, or in cases where we want to receive multiple data types, the data type of object is used. Object is like a rubber man; it can fit anywhere and everywhere. By giving the function name abc to the function QueueUserWorkItem, abc will be called five times by a thread. The function waits for a small amount of time at an event and then uses the function GetHashCode to print the name/id of the thread. This function will print the thread id that is calling abc.
From our output, we can conclude that only two threads execute the function abc. Commenting the Wait statement will display the same id for the thread. This means that no new thread executes the function. Thus, instead of two threads, only a single thread is used. Efficiency, thy name is Thread Pool.
We are thus posting work items to a common place or thread pool. Then, a thread is allocated to execute the work item or function. The first available thread from the thread pool executes the function. We are only using one thread pool per program.
There is a lot of overhead in managing threads. A lot of time is spent figuring out which thread is sleeping, i.e. waiting for an event to occur. Most of the time, threads are in this inert state. At times, threads wake up to check/poll for a change that is expected to occur, such as a key press, or to update some counter or status information and fall asleep again. Threads are like bears, they love sleeping.
Thread Pooling is a means of managing threads more efficiently. This is done by providing your application with a pool of threads that are managed by the system. All threads that do work are called worker threads. There is a thread that monitors the status of threads waiting at any of the wait functions. When the wait is over, the callback function will be executed.
The next program demonstrates how a function can be called after a specified time duration has elapsed. There is no way to cancel a function from being executed once it has gone into the thread pool. A prayer will also not help. Timers and Waits use the thread pool without our knowledge.
The thread pool is created when we call the function QueueUserWorkItem for the first time or when we use a timer function. The number of threads that form part of a thread pool is limited by the amount of memory available. By today's standards, this means that more threads can be made available than we would ever need. These threads receive the default stack size and run at the default priority. No special priority is accorded. For the trivia fans, a thread can handle up to 63 wait operations. No concept is perfect. Thus, one significant disadvantage of a thread pool is that it involves a long calculation.
a.cs
using System;
using System.Threading;
public class yyy
{
public void abc(object s, bool b)
{
Console.WriteLine("{0} {1}", Thread.CurrentThread.GetHashCode(),b);
}
};
public class zzz
{
public static void Main()
{
ManualResetEvent a = new ManualResetEvent(false);
ManualResetEvent b = new ManualResetEvent(false);
yyy y = new yyy();
ThreadPool.RegisterWaitForSingleObject(a,new WaitOrTimerCallback(y.abc),1,1000,true);
b.WaitOne(10000,true);
}
}
Output
2 True
As mentioned earlier, we would like our function to be called after a certain wait. To accomplish this, we use a function with a very large name called RegisterWaitForSingleObject. The first parameter is the handle of an event. This has been set to false or non signaled. The second parameter is a delegate of type WaitOrTimerCallback which is similar to a WaitCallback. The difference is that the signature of the function given to this function, which is abc, has to have two parameters, viz. an object and a boolean variable. The third parameter is the object that is to be passed to the function. The second last parameter is a timer that decides the duration after which the function should be called. Finally, the last parameter decides whether the function is to be executed only once or every time the timer expires.
As our event object is set to false, the function gets called after 1000 milliseconds. When the timer expires, the function abc obtains a value of true.
By merely changing one line in the above example, the event can be changed to a signaled state.
ManualResetEvent a = new ManualResetEvent(true);
Output
2 False
The function abc gets called immediately, unlike in the earlier program. Also, there is no wait as the event is true or signaled. The function abc also knows why it has been called since the bool parameter has a value of false, which was true in the earlier case. Thus, the function abc can look at the value of its second parameter, which indicates whether the timer has elapsed or the event has been signaled.
a.cs
using System;
using System.Threading;
public class yyy
{
public void Beta(object s, bool b)
{
Console.WriteLine("{0} {1}", Thread.CurrentThread.GetHashCode(),b);
}
};
public class zzz
{
public static void Main()
{
ManualResetEvent a = new ManualResetEvent(false);
ManualResetEvent b = new ManualResetEvent(false);
yyy y = new yyy();
ThreadPool.RegisterWaitForSingleObject(a,new WaitOrTimerCallback(y.Beta),1,10000,true);
a.Set();
b.WaitOne(10000,true);
}
}
Output
2 False
In this program, initially we set the event to false and then, using the Set function, we set it to true immediately. Thus, the function gets called instantly. You would remember that the function gets called whenever the event is in a signaled state or the timer expires. This function first checks whether the wait object is signaled or not. If it is signaled, it executes the function. If it is not, it waits for the timer to elapse or the wait object to come into the signaled state, whichever occurs first.
Interlocked
a.cs
using System;
using System.Threading;
public class yyy
{
public ManualResetEvent a = new ManualResetEvent(false);
int i = 10;
public void abc(Object s)
{
Interlocked.Increment(ref i);
Console.WriteLine("{0} {1}", Thread.CurrentThread.GetHashCode(),i);
}
};
public class zzz
{
public static void Main() {
ManualResetEvent b = new ManualResetEvent(false);
yyy y = new yyy();
for (int i=1;i<=5;i++)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(y.abc),1);
}
b.WaitOne(10000,true);
}
}
Output
2 11
2 12
2 13
2 14
2 15
Threads can be dangerous for the unwary. The function abc gets called five times by the same or a different thread. Consider a case where one thread may be incrementing the line i = i + 1. To do so, it will start by asking what is the value of i. Let us suppose that it is 10. It then increments the value by 1 to make it 11. It may so happen that just as it is about to read its value, its time slice may get over and another thread may increment the variable i by 1 to make its value 12.
When the first thread receives its next time slice and checks the value of i, it will see the value as 12 and not 11. Thus, the variable would have been incremented twice instead of once.
The Interlocked class has a sole purpose in life, i.e. to ensure that the variables are not incremented more than once. In a sense, it synchronizes access to a variable that is being shared by a number of threads. The operation will either be done in a single time slice or not done at all. It will not be carried over into another time slice ever. These operations, which are guaranteed to be finished in a single time slice, are called atomic operations.
a.cs
using System;
using System.Threading;
public class yyy
{
public ManualResetEvent a = new ManualResetEvent(false);
public int i = 10;
public void abc(Object s)
{
i++;
Interlocked.CompareExchange(ref i,100,12);
}
};
public class zzz
{
public static void Main()
{
ManualResetEvent b = new ManualResetEvent(false);
yyy y = new yyy();
for (int i=1;i<=5;i++)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(y.abc),1);
}
b.WaitOne(1000,true);
Console.WriteLine(y.i);
}
}
Output
103
The function abc gets called five times. If we intend to carry out comparisons, we would face the above dilemma. Thus, we use a simple function called CompareExchange. This functions checks the value of the first parameter that is passed as a reference, with the third parameter, which in our case is 12. If it matches the value, the first parameter i.e. i is assigned the value of the second parameter i.e. 100. All this is done in a single time slice. Thus, whenever variable i becomes 12, its value shoots up to 100, and as a result, the final answer becomes 103.
Like the Increment, there is a Decrement function also that reduces the value of a variable by one. As an aside, a ref parameter cannot be replaced by an out parameter. In the same vein, the Exchange function changes the value of two variables passed to it as ref parameters. This is done in an atomic manner.