This chapter is from the book
This chapter is from the book
This chapter is from the book
.NET Application Model
Serialization gave you a concrete example of the flexible environment the .NET Framework provides for writing code. Now let us take a look at the model in which .NET applications run. The Win32 environment in which a program runs is called its process. This environment consists of
An address space in which the code and data of the program resides.
A set of environment variables that is associated with the program.
A current drive and directory.
One or more threads.
Threads
A thread is the actual execution path of a program's code. One or more threads run inside of a process to allow for multiple execution paths inside of a process. For example, with multiple threads a program can update the user interface with partial results on one thread as a calculation proceeds on another thread. All threads in the same process share the process environment so that all the threads can access the process memory.
Threads are scheduled by the operating system. Processes and application domains10 are not scheduled. Threads are periodically given a limited timeslice in which to run so that they can share the processor with other threads. Higher priority threads will get to run more often than lower priority threads. After some time elapses, a thread will get another chance to run. When a thread is swapped back in, it resumes running from the point it was at when it was swapped out.
Threads maintain a context that is saved and restored when the operating system's scheduler switches from one thread to another. A thread's context includes the CPU registers and stack that contain the state of the executing code.
The System::Threading::Thread class models an executing thread. The Thread object that represents the current executing thread can be found from the static property Thread::CurrentThread.
Unless your code runs on a multiprocessor machine, or you are trying to use time while a uniprocessor waits for some event such as an I/O event, multiple threads do not result in any time saved for your computing tasks. It does, however, make the system seem more responsive to tasks requiring user interaction. Using too many threads can decrease performance, as thread management overhead and contention between competing threads burdens the CPU.
To help you understand threads, we have a multiple-step Threading example11 that uses the Customer and Hotel assemblies from the case study to make reservations. Let us look first at Step 0.
.NET threads run as delegates defined by the ThreadStart class. The delegate returns void and takes no parameters.
public __gc __delegate void ThreadStart();
The NewReservation class has a public member function, MakeReservation, that will define the thread function. Since the thread function takes no parameters, any data that this function uses is assigned to fields in the NewReservation instance.
The thread delegate is created and passed as a parameter to the constructor that creates the Thread object. The Start method on the Thread object is invoked to begin the thread's execution. When we discuss the asynchronous programming model, we will show you how to pass parameters to a thread delegate. The program now has two threads: the original one that executed the code to start the thread and now the thread we just created that attempts to make a hotel reservation.
public __gc class NewReservation
{
...
public:
...
void MakeReservation()
{
Console::WriteLine(
"Thread {0} starting.",
Thread::CurrentThread->
GetHashCode().ToString());
...
ReservationResult *result =
hotelBroker->MakeReservation(
customerId, city, hotel, date, numberDays);
...
}
};
Then, in the Main method, the following code starts the thread, using a delegate:
NewReservation *reserve1 =
new NewReservation(customers, hotelBroker);
reserve1->customerId = 1;
reserve1->city = "Boston";
reserve1->hotel = "Presidential";
reserve1->sdate = "12/12/2001";
reserve1->numberDays = 3;
// create delegate for threads
ThreadStart *threadStart1 = new ThreadStart(
reserve1,
reserve1->MakeReservation);
Thread *thread1 = new Thread(threadStart1);
Console::WriteLine(
"Thread {0} starting a new thread.",
Thread::CurrentThread->
GetHashCode().ToString());
thread1->Start();
To cause the original thread to wait until the second thread is done, the Join method on the Thread object is called. The original thread now blocks (waits) until the reservation thread is complete. The results of the reservation request are written to the console by the reservation thread.
// Block this thread until the worker thread is done
thread1->Join();
Console::WriteLine("Done!");
Thread Synchronization
An application can create multiple threads. Look at the code in Step 1 of the Threading example. Now multiple reservation requests are being made simultaneously.
NewReservation *reserve1 =
new NewReservation(customers, hotelBroker);
...
NewReservation *reserve2 =
new NewReservation(customers, hotelBroker);
...
// create delegate for threads
ThreadStart *threadStart1 = new ThreadStart(
reserve1,
reserve1->MakeReservation);
ThreadStart *threadStart2 = new ThreadStart(
reserve2,
reserve2->MakeReservation);
Thread *thread1 = new Thread(threadStart1);
Thread *thread2 = new Thread(threadStart2);
Console::WriteLine(
"Thread {0} starting a new thread.",
Thread::CurrentThread->
GetHashCode().ToString());
thread1->Start();
thread2->Start();
// Block this thread until the worker thread is done
thread1->Join();
thread2->Join();
The problem with our reservation system is that there is no guarantee that one thread will not interfere with the work being done by the other thread. Since threads run for only a small period before they give up the processor to another thread, they may not be finished with whatever operation they were working on when their timeslice is up. For example, they might be in the middle of updating a data structure. If another thread tries to use the information in that data structure or to update the data structure, the results of those operations will be inconsistent and incorrect, or a program crash could result (i.e., if references to obsolete structures were not yet updated, an unhandled exception could occur).
Let us look at one of several places in the customer and reservation code where we could have a problem. Examine the code for Broker::Reserve in Broker.h. First, a check is made of the existing bookings for a given hotel for a given date to see if there are rooms available. Then, if a room is available, it is reserved. Note that we have added a call to Thread::Sleep between the code that checks for room availability and the code that reserves a room, which will be explained shortly.
...
// Check if rooms are available for all dates
for (int i = day; i < day + numDays; i++)
{
if (numCust[i, unitid] >= unit->capacity)
{
result->ReservationId = -1;
result->Comment = "Room not available";
return result;
}
}
Console::WriteLine(
"Thread {0} finds the room is available in
@@ Broker::Reserve",
Thread::CurrentThread->
GetHashCode().ToString());
Thread::Sleep(0);
// Reserve a room for requested dates
for (int i = day; i < day + numDays; i++)
numCust[i, unitid] += 1;
...
This code can produce inconsistent results! One of the threads could be swapped out after it finds that the last room is available, but before it gets a chance to make the booking. The other thread could then run, find the same available room and make the booking. When the first thread runs again, it starts from where it left off, and it will also book the same last room at the hotel.
To simulate this occurrence, this step (Step 1) of the Threading example puts a Thread::Sleep call between the code that checks for room availability and the code that makes the booking. The Sleep(0) call will cause the thread to stop executing and give up the remainder of its timeslice.
To ensure that we see the thread contention problem occur,12 we have only one room in the entire hotel! We then set up our program so that the two threads try to reserve the only room at the hotel for the same date. Examine the code in the Main routine that sets this up:
hotelBroker->AddHotel(
"Boston",
"Presidential",
1, //only one room in entire hotel!
(Decimal) 10000);
...
NewReservation *reserve1 =
new NewReservation(customers, hotelBroker);
reserve1->customerId = 1;
reserve1->city = "Boston";
reserve1->hotel = "Presidential";
reserve1->sdate = "12/12/2001";
reserve1->numberDays = 3;
NewReservation *reserve2 =
new NewReservation(customers, hotelBroker);
reserve2->customerId = 2;
reserve2->city = "Boston";
reserve2->hotel = "Presidential";
reserve2->sdate = "12/13/2001";
reserve2->numberDays = 1;
Running the program will give results that look something like this:
Added Boston Presidential Hotel with one room. Thread 3 starting a new thread. Thread 5 starting. Thread 6 starting. Reserving for Customer 2 at the Boston Presidential Hotel on 12/13/2001 12:00:00 AM for 1 days Reserving for Customer 1 at the Boston Presidential Hotel on 12/12/2001 12:00:00 AM for 3 days Thread 6 entered Broker::Reserve Thread 6 finds the room is available in Broker::Reserve Thread 5 entered Broker::Reserve Thread 5 finds the room is available in Broker::Reserve Thread 6 left Broker::Reserve Reservation for Customer 2 has been booked ReservationId = 1 Thread 5 left Broker::Reserve Reservation for Customer 1 has been booked ReservationId = 2 ReservationRate = 10000 ReservationCost = 30000 Comment = OK ReservationRate = 10000 ReservationCost = 10000 Comment = OK Done!
Unfortunately, both customers get to reserve the last (only) room on December 13! Note how one thread enters the Reserve method and finds the room is available before it gets swapped out. Then, the other thread enters Reserve and also finds the room is available before it gets swapped out. Both threads then book the same room.
Operating systems provide means for synchronizing the operation of multiple threads or multiple processes accessing shared resources. The .NET Framework provides several mechanisms to prevent threading conflicts.
Every object in the .NET Framework can be used to provide a synchronized section of code (critical section). Only one thread at a time can execute within such a section. If one thread is already executing inside that synchronized code section, any other threads that attempt to access that section will block (wait) until the executing thread leaves that code section.
Synchronization with Monitors
The System::Threading::Monitor class allows threads to synchronize on an object to avoid the data corruption and indeterminate behavior that can result from race conditions. Step 2 of the Threading example demonstrates the use of the Monitor class with the this pointer of the HotelBroker instance.
ReservationResult *Reserve(Reservation *res)
{
Console::WriteLine(
"Thread {0} trying to enter Broker::Reserve",
Thread::CurrentThread->
GetHashCode().ToString());
Monitor::Enter(this);
... (thread contentious code goes here)
Monitor::Exit(this);
return result;
}
The thread that first calls the Monitor::Enter(this) method will be allowed to execute the code of the Reserve method because it will acquire the Monitor lock based on the this pointer. Subsequent threads that try to execute the same code will have to wait until the first thread releases the lock with Monitor::Exit(this). At that point they will be able to call Monitor::Enter(this) and acquire the lock.
A thread can call Monitor::Enter several times, but each call must be balanced by a call to Monitor::Exit. If a thread wants to try to acquire a lock, but does not want to block, it can use the Monitor::TryEnter method.
Now that we have provided synchronization, the identical case tried in Step 1 does not result in one reservation too many for the hotel. Notice how the second thread cannot enter the Reserve method until the first thread that entered has left. This solves our thread contention problem and enforces the rule that the same room cannot be booked by two customers for the same date.
Added Boston Presidential Hotel with one room. Thread 3 starting a new thread. Thread 5 starting. Thread 6 starting. Reserving for Customer 2 at the Boston Presidential Hotel on 12/13/2001 12:00:00 AM for 1 days Thread 6 trying to enter Broker::Reserve Thread 6 entered Broker::Reserve Thread 6 finds the room is available in Broker::Reserve Thread 6 left Broker::Reserve Reservation for Customer 2 has been booked ReservationId = 1 Reserving for Customer 1 at the Boston Presidential Hotel on 12/12/2001 12:00:00 AM for 3 days Thread 5 trying to enter Broker::Reserve Thread 5 entered Broker::Reserve Reservation for Customer 1 could not be booked Room not available ReservationRate = 10000 ReservationCost = 10000 Comment = OK Done!
Notification with Monitors
A thread that has acquired a Monitor lock can wait for a signal from another thread that is synchronizing on that same object without leaving the synchronization block. The thread invokes the Monitor::Wait method and relinquishes the lock. When notified by another thread, it reacquires the synchronization lock.
A thread that has acquired a Monitor lock can send notification to another thread waiting on the same object with the Pulse or the PulseAll methods. It is important that the thread be waiting when the pulse is sent; otherwise, if the pulse is sent before the wait, the other thread will wait forever and will never see the notification. This is unlike the reset events discussed later in this chapter. If multiple threads are waiting, the Pulse method will put only one thread on the ready queue to run. The PulseAll will put all of them on the ready queue.
The pulsing thread no longer has the Monitor lock, but is not blocked from running. Since it is no longer blocked, but does not have the lock, to avoid a deadlock or race condition, this thread should try to reacquire the lock (through a Monitor::Enter or Wait) before doing any potentially damaging work.
The PulseAll example illustrates the Pulse and PulseAll methods. Running the example produces the following output:
First thread: 2 started. Thread: 5 started. Thread: 5 waiting. Thread: 6 started. Thread: 6 waiting. Thread 5 sleeping. Done. Thread 5 awake. Thread: 5 exited. Thread 6 sleeping. Thread 6 awake. Thread: 6 exited.
The class X has a field "o" of type Object that will be used for a synchronization lock.
The class also has a method Test that will be used as a thread delegate. The method acquires the synchronization lock, and then waits for a notification. When it gets the notification, it sleeps for half a second, and then relinquishes the lock.
The main method creates two threads that use the X::Test method as their thread delegate and share the same object to use for synchronization. It then sleeps for 2 seconds to allow the threads to issue their wait requests and relinquish their locks. It then calls PulseAll to notify both waiting threads and relinquishes its hold on the locks. Eventually, each thread will reacquire the lock, write a message to the console, and relinquish the lock for the last time.
__gc class X
{
private:
Object *o;
public:
X(Object *o)
{
this->o = o;
}
void Test()
{
try
{
long threadId =
Thread::CurrentThread->GetHashCode();
Console::WriteLine(
"Thread: {0} started.", threadId.ToString());
Monitor::Enter(o);
Console::WriteLine(
"Thread: {0} waiting.", threadId.ToString());
Monitor::Wait(o);
Console::WriteLine(
"Thread {0} sleeping.", threadId.ToString());
Thread::Sleep(500);
Console::WriteLine(
"Thread {0} awake.", threadId.ToString());
Monitor::Exit(o);
Console::WriteLine(
"Thread: {0} exited.", threadId.ToString());
}
catch(Exception *e)
{
long threadId =
Thread::CurrentThread->GetHashCode();
Console::WriteLine(
"Thread: {0} Exception: {1}",
threadId.ToString(), e->Message);
Monitor::Exit(o);
}
}
};
__gc class Class1
{
public:
static Object *o = new Object;
static void Main()
{
Console::WriteLine(
"First thread: {0} started.",
Thread::CurrentThread->GetHashCode().ToString());
X *a = new X(o);
X *b = new X(o);
ThreadStart *ats = new ThreadStart(a, X::Test);
ThreadStart *bts = new ThreadStart(b, X::Test);
Thread *at = new Thread(ats);
Thread *bt = new Thread(bts);
at->Start();
bt->Start();
// Sleep to allow other threads to wait on the
// object before the Pulse
Thread::Sleep(2000);
Monitor::Enter(o);
Monitor::PulseAll(o);
//Monitor::Pulse(o);
Monitor::Exit(o);
Console::WriteLine("Done.");
}
};
Comment out the PulseAll call and uncomment the Pulse call, and only one thread completes because the other thread is never put on the ready queue. Remove the Sleep(2000) from the main routine, and the other threads block forever because the pulse occurs before the threads get a chance to call the Wait method, and hence they will never be notified. These methods can be used to coordinate several threads' use of synchronization locks.
The Thread::Sleep method causes the current thread to stop execution (block) for a given time period. Calling Thread::Suspend will cause the thread to block until Thread::Resume is called by another thread on that same thread. Threads can also block because they are waiting for another thread to finish (Thread::Join). This method was used in the Threading examples so that the main thread could wait until the reservation requests were completed. Threads can also block because they are waiting on a synchronization lock (critical section).
Calling Thread::Interrupt on the blocked thread can awaken it. The thread will receive a ThreadInterruptedException. If the thread does not catch this exception, the runtime will catch the exception and kill the thread.
If, as a last resort, you have to kill a thread outright, call the Thread::Abort method on the thread. Thread::Abort causes the ThreadAbortException to be thrown. This exception cannot be caught, but it will cause all the finally blocks to be executed. In addition, Thread::Abort does not cause the thread to wake up from a wait.
Since finally blocks may take a while to execute, or the thread might be waiting, aborted threads may not terminate immediately. If you need to be sure that the thread has finished, you should wait on the thread's termination using Thread::Join.
Synchronization Classes
The .NET Framework has classes that represent the standard Win32 synchronization objects. These classes all derive from the abstract WaitHandle class. This class has static methods, WaitAll and WaitAny, that allow you to wait on a set or just one of a set of synchronization objects being signaled. It also has an instance method, WaitOne, that allows you to wait for this instance to be signaled. How the object gets signaled depends on the particular type of synchronization object that is derived from WaitHandle.
A Mutex object is used for interprocess synchronization. Monitors and synchronized code sections work only within one process. An AutoResetEvent and ManualResetEvent are used to signal whether an event has occurred. An AutoResetEvent remains signaled until a waiting thread is released. A ManualResetEvent remains signaled until its state is set to unsignaled with the Reset method. Hence, many threads could be signaled by this event. Unlike Monitors, code does not have to be waiting for the signal before the pulse is set for the reset events to signal a thread.
The framework has provided classes to solve some standard threading problems. The Interlocked class methods allow atomic operations on shared values such as increment, decrement, comparison, and exchange. ReaderWriterLock is used to allow single-writer, multiple-reader access to data structures. The ThreadPool class can be used to manage a pool of worker threads.
Automatic Synchronization
You can use attributes to synchronize the access to instance methods and fields of a class. Access to static fields and methods is not synchronized. To do this, you derive the class from the class System::ContextBoundObject and apply a Synchronization attribute to the class. This attribute cannot be applied to an individual method or field.
The attribute is found in the System::Runtime::Remoting::Contexts namespace. It describes the synchronization requirements of an instance of the class to which it is applied. You can pass one of four values, which are static fields of the SynchronizationAttribute class, to the SynchronizationAttribute constructor: NOT_SUPPORTED, SUPPORTED, REQUIRED, REQUIRES_NEW. The Threading example Step 3 illustrates how to do this.
...
using namespace System::Runtime::Remoting::Contexts;
...
//SynchronizationAttribute::REQUIRED is 4
[Synchronization(4)]
public __gc __abstract class Broker :
public ContextBoundObject
{
...
};
...
In order for the CLR to make sure that the thread in which an object's methods run is synchronized properly, the CLR has to track the threading requirements of the object. This state is referred to as the context of the object. If one object needs to be synchronized, and another does not, they are in two separate contexts. The CLR has to acquire a synchronization lock on behalf of the code when a thread that is executing a method on the object that does not need to be synchronized starts executing a method on an object that does. The CLR knows that this has to be done because it can compare the threading requirements of the first object with the threading requirements of the second object by comparing their contexts.
Objects that share the same state are said to live in the same context. For example, two objects that do not need to be synchronized can share the same context. ContextBoundObject and contexts are discussed in more detail in the section on contexts.
With this intuitive understanding of contexts, we can now explain the meaning of the various Synchronization attributes. NOT_SUPPORTED means that the class cannot support synchronization of its instance methods and fields and therefore must not be created in a synchronized context. REQUIRED means that the class requires synchronization of access to its instance methods and fields. If a thread is already being synchronized, however, it can use the same synchronization lock and live in an existing synchronization context. REQUIRES_NEW means that not only is synchronization required, but access to its instance methods and fields must be with a unique synchronization lock and context. SUPPORTED means that the class does not require synchronization of access to its instance methods and fields, but a new context does not have to be created for it.
You can also pass a bool flag to the constructor to indicate if reentrancy is required. If required, call-outs from methods are synchronized. Otherwise, only calls into methods are synchronized.
With the Synchronization attribute, there is no need for Monitor::Enter and Monitor::Exit in the Broker::Reserve method.
Just as in Step 2, this example attempts to make two reservations for the last room in a hotel. Here is the output from running this example:
Added Boston Presidential Hotel with one room. Thread 13 starting a new thread. Thread 28 starting. Thread 29 starting. Reserving for Customer 1 at the Boston Presidential Hotel on 12/12/2001 12:00:00 AM for 3 days Thread 28 entered Broker::Reserve Thread 28 finds the room is available in Broker::Reserve Thread 28 left Broker::Reserve Reservation for Customer 1 has been booked ReservationId = 1 ReservationRate = 10000 ReservationCost = 30000 Comment = OK Reserving for Customer 2 at the Boston Presidential Hotel on 12/13/2001 12:00:00 AM for 1 days Thread 29 entered Broker::Reserve Thread 29 left Reserve. Reservation for Customer 2 could not be booked Room not available Done!
As in the previous case, the second thread could not enter the Reserve method until the thread that entered first finished. Only one reservation is made.
What is different about using this automatic approach is that you get the synchronization in all the methods of the class whether you need it or not. Accessing other shared data via other methods in the class is also blocked. You get this behavior whether you want it or not.
Note how only one thread can be in any method of the class at any given time. Assume that you added another method to the class named CancelReservation. If one thread called CancelReservation, it would block all other threads from calling other methods in the class, including MakeReservation. With a reservation system, this is the behavior you would want, since you do not want the MakeReservation attempt to use a data structure that might be in the middle of being modified. In some situations, however, this is not desirable and reduces performance due to unnecessary blocking. The resulting increase in contention can interfere with scalability, since you are not just locking around the specific areas that need synchronizing.
The attribute approach is simpler than using critical sections. You do not have to worry about the details of getting the synchronization implemented correctly. On the other hand, you get behavior that reduces scalability. Different applications or different parts of the same application will benefit from the approach that makes the most sense.
Thread Isolation
An exception generated by one thread will not cause another thread to fail. The ThreadIsolation example demonstrates this.
__gc class tm
{
public:
void m()
{
Console::WriteLine(
"Thread {0} started",
Thread::CurrentThread->GetHashCode().ToString());
Thread::Sleep(1000);
for(int i = 0; i < 10; i++)
Console::WriteLine(i);
Console::WriteLine(
"Thread {0} done",
Thread::CurrentThread->GetHashCode().ToString());
}
};
__gc class te
{
public:
void tue()
{
Console::WriteLine(
"Thread {0} started",
Thread::CurrentThread->GetHashCode().ToString());
Exception *e = new Exception("Thread Exception");
throw e;
}
};
__gc class ThreadIsolation
{
public:
static void Main()
{
tm *tt = new tm;
te *tex = new te;
// create delegate for threads
ThreadStart *ts1 = new ThreadStart(tt, tm::m);
ThreadStart *ts2 = new ThreadStart(tex, te::tue);
Thread *thread1 = new Thread(ts1);
Thread *thread2 = new Thread(ts2);
Console::WriteLine(
"Thread {0} starting new threads.",
Thread::CurrentThread->GetHashCode().ToString());
thread1->Start();
thread2->Start();
Console::WriteLine(
"Thread {0} done.",
Thread::CurrentThread->GetHashCode().ToString());
}
};
The following output is generated. Note how the second thread can continue to write out the numbers even though the first thread has aborted from the unhandled exception. Note also how the "main" thread that spawned the other two threads can finish without causing the other threads to terminate.
Thread 2 starting new threads. Thread 2 done. Thread 5 started Thread 6 started Unhandled Exception: System.Exception: Thread Exception @@at te.tue() in c:\oi\netcpp\chap8\threadisolation@@ threadisolation.h:line 32 0 1 2 3 4 5 6 7 8 9 Thread 5 done
The AppDomain class (discussed later in the chapter) allows you to set up a handler to catch an UnhandledException event.
Synchronization of Collections
Some lists, such as TraceListeners, are thread safe. When this collection is modified, a copy is modified and the reference is set to the copy. Most collections, like ArrayList, are not thread safe. Making them automatically thread safe would decrease the performance of the collection even when thread safety is not an issue.
An ArrayList has a static Synchronized method to return a thread-safe version of the ArrayList. The IsSynchronized property allows you to test if the ArrayList you are using is the thread-safe version. The SyncRoot property can return an object that can be used to synchronize access to a collection. This allows other threads that might be using the ArrayList to be synchronized with the same object.