.NET Application Model

for RuBoard

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

• the address space in which the code and data of the program reside

• one or more threads

• a set of environmental variables that is associated with the program

• a current drive and directory

Threads

A thread is the actual execution path of a program's code. One or more threads run inside a process to allow for multiple execution paths inside a process. With multiple threads, for example, 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 they can all access process memory.

Threads are scheduled by the operating system; processes and application domains ^[9] are not scheduled. Threads are 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 restarted, it resumes running from where it was stopped .

^[9] Application domains are discussed later in this chapter.

Threads maintain a context, which has to be saved and restored when the operating system's scheduler switches from one thread to another. A thread's context includes the machine 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 System.Threading.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, using multiple threads does not save any time on your computing tasks . It does, however, allow making the system seem more responsive to tasks requiring user interaction. Using too many threads can decrease performance as contention between the threads for the CPU increases .

To help you understand threads we provide a four-part Threading example that uses the Customer and Hotel assemblies from the case study to make reservations . Let us look first at Step 0. The code is found in the file Threading.cs .

.NET threads run as delegates defined by the System.Threading. ThreadStart class. The delegate returns void and takes no parameters.

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

 ThreadStart threadStart1 = new      ThreadStart(reserve1.MakeReservation); 

The thread delegate is created and passed as a parameter to the constructor that creates the System.Threading.Thread instance. The Start method on the Thread instance 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 program, and the thread we have just created that attempts to make a hotel reservation.

 public class NewReservation    {    . . .    public void MakeReservation()    {      . . .        Console.WriteLine("Thread {0} starting.",          Thread.CurrentThread.GetHashCode());      . . .        ReservationResult result =          hotelBroker.MakeReservation(customerId, city, hotel,          date, numberDays);      . . .    }  }    . . .    NewReservation reserve1 = new NewReservation(customers,        hotelBroker);    reserve1.customerId = 1;    reserve1.city = "Boston";    reserve1.hotel = "Presidential";    reserve1.sdate = "12/12/2001";   reserve1.numberDays = 3;  ThreadStart threadStart1 = new      ThreadStart(reserve1.MakeReservation);  Thread thread1 = new Thread(threadStart1);  Console.WriteLine("Thread {0} starting a new thread.",      Thread.CurrentThread.GetHashCode());  thread1.Start(); 

To cause the original thread to wait until the second thread is done, the Join method on the System.Threading.Thread instance 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.

 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);  . . .  ThreadStart threadStart1 = new                    ThreadStart(reserve1.MakeReservation);  ThreadStart threadStart2 = new                    ThreadStart(reserve2.MakeReservation);  Thread thread1 = new Thread(threadStart1);  Thread thread2 = new Thread(threadStart2);  thread1.Start();  thread2.Start();  thread1.Join();  thread2.Join(); 

The problem with our reservation systems is that there is no guarantee that one thread will not interfere with the work being done with the other thread. Threads run only for a brief period before they are interrupted and another thread is scheduled to run on the processor. 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 update the data structure, the results of operations will be at best inconsistent and incorrect, and at worst a system crash (i.e., if references to obsolete structures were not yet updated).

Let us look at one of several places in the customer and reservation code where we could have a problem. Examine the code for the Reserve method in the file broker.cs . First a check is made of the existing bookings for a given hotel for a given date to see if rooms are available. If there are, the booking is made.

 . . .  // 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;    }  }  . . .  // 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 thread could be rescheduled after it finds that the last room is available, but before it gets a chance to make the booking. The other thread could run, find the same available room, and make the booking. When the second thread runs again, starting from where it left off, it will also book the last room at the hotel.

To simulate this occurrence, this step of the threading example puts a System.Threading.Thread.Sleep call between the code that checks for 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. We then setup our program so that the two threads try to reserve the only room at a hotel for the same time. Examine the code in the Main routine that sets this up:

 hotelBroker.AddHotel("Boston", "Presidential", 1,                      (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 something like this:

 Added Boston Presidential Hotel with one room.  Thread 3 starting  new threads.  Thread 5 starting.  Reserving for Customer 1 at the Boston Presidential Hotel  on 12/12/2001 12:00:00 AM for 3 days  Thread 5 entered Broker::Reserve  Thread 5 sleeping in Broker::Reserve  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 entered Broker::Reserve  Thread 6 sleeping in Broker::Reserve  Thread 5 left Broker::Reserve  Reservation for Customer 1 has been booked  ReservationId = 1  ReservationRate = 10000  ReservationCost = 30000  Comment = OK  Thread 6 left Broker::Reserve  Reservation for Customer 2 has been booked  ReservationId = 2  ReservationRate = 10000  ReservationCost = 10000  Comment = OK  Done! 

Both customers get to reserve the last room on December 13! Note how Thread 5 enters the Reserve method and finds the room is available before it gets rescheduled. Thread 6 enters Reserve and also finds the room is available before it gets rescheduled. Thread 5 then books the room, and Thread 6 does as well.

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 threads that attempt to access that section will block (wait) until the executing thread leaves it.

Synchronization with Monitors

The System.Threading.Monitor class allows you to create a critical section by synchronizing on an object to avoid race conditions or incorrect answers. Step 2 of the Threading example demonstrates the use of the Monitor class with the this pointer of the HotelBroker instance.

 public ReservationResult Reserve(Reservation res)  {    . . .    Monitor.Enter(this);    . . .    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 will be forced 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 so that it can do some work and try again, it can use the Monitor.TryEnter method.

In C# you can use the lock keyword in place of Monitor.Enter/Exit . With the lock keyword, the above fragment would be:

 public ReservationResult Reserve(Reservation res)  {    lock(this);    {      . . .    }    return result;  } 

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.

 Added Boston Presidential Hotel with one room.  Thread 3 launching 2 threads.  Thread 5 starting.  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  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 5 left Broker::Reserve  Thread 6 entered Broker::Reserve  Thread 6 left Broker::Reserve  Reservation for Customer 2 could not be booked  Room not available  Reservation for Customer 1 has been booked  ReservationId = 1  ReservationRate = 10000  ReservationCost = 30000  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 receiving 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: 6 started.  Thread: 6 waiting.  Thread: 5 waiting.  Thread 6 sleeping.  Done.  Thread 6 awake.  Thread: 6 exited.  Thread 5 sleeping.  Thread 5 awake.  Thread: 5 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 Test method of class X 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. Next it 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.

 class X  {    object o;    public X(object o)    {      this.o = o;    }    public void Test()    {      try        {          long threadId =Thread.CurrentThread.GetHashCode();          Console.WriteLine("Thread:{0} started.",threadId);          Monitor.Enter(o);          Console.WriteLine("Thread:{0} waiting.",threadId);          Monitor.Wait(o);          Console.WriteLine("Thread {0} sleeping",threadId);          Thread.Sleep(500);           Console.WriteLine("Thread {0} awake.", threadId);          Monitor.Exit(o);          Console.WriteLine("Thread: {0} exited.",threadId);        }      catch(Exception e)          {          long threadId =Thread.CurrentThread.GetHashCode();          Console.WriteLine("Thread: {0} Exception: {1}",                             threadId, e.Message);          Monitor.Exit(o);        }    }  }  class Class1  {    static public object o = new object();    static void Main(string[] args)    {      Console.WriteLine("First thread: {0} started.",                       Thread.CurrentThread.GetHashCode());      X a = new X(o);      X b = new X(o);      ThreadStart ats = new ThreadStart(a.Test);      ThreadStart bts = new ThreadStart(b.Test);      Thread at = new Thread(ats);      Thread bt = new Thread(bts);      at.Start();      bt.Start();      Thread.Sleep(2000);      Monitor.Enter(o);      Monitor.PulseAll(o);      // Monitor.Pulse(o);      Monitor.Exit(o);      Console.WriteLine("Done.");    }  } 

Comment out the PulseAll call, 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 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.

A blocked thread can be awakened by calling Thread.Interrupt on the blocked thread. The thread will receive a ThreadInterruptedException . If it does not catch this exception, the runtime will catch it 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 for all of a set of synchronization objects being signaled or on 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 SynchronizatonAttribute constructor: NOT_SUPPORTED, SUPPORTED, REQUIRED, REQUIRES_NEW. The Threading example Step 3 illustrates how to do this.

 Synchronization(SynchronizationAttribute.REQUIRED)]  public abstract class Broker : ContextBoundObject  {  . . . 

In order for the CLR to make sure that the thread in which this object runs on is synchronized properly, the CLR has to track the threading requirements of this 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 Boolean 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 this 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. In addition, a third thread attempts to cancel a reservation. Here is the output from running this example:

 Added Boston Presidential Hotel with one room.  Thread 13 launching 3 threads.  MakeReservation: Thread 28 starting.  Reserving for Customer 1 at the Boston Presidential Hotel  on 12/12/2001 12:00:00 AM for 3 days  Thread 28 entered Reserve.  MakeReservation: Thread 29 starting.  Reserving for Customer 2 at the Boston Presidential Hotel  on 12/13/2001 12:00:00 AM for 1 days  CancelReservation: Thread 30 starting.  Cancelling Reservation 10  Thread 28 left Reserve.  Thread 29 entered Reserve.  Thread 29 left Reserve.  Reservation for Customer 2 could not be booked  Room not available  Thread 30 entered CancelReservation.  Thread 30 left CancelReservation.  Reservation for Customer 1 has been booked  ReservationId = 1  ReservationRate = 10000  ReservationCost = 30000  Comment = OK  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 the automatic approach is that you get the synchronization in all the methods of the class whether you need it or not. Accessing any data in the class is also singly threaded.

Note how only one thread can be in any method of the class; a thread using CancelReservation blocks threads from using MakeReservation . With a reservation system this is the behavior you want, since you do not want the MakeReservation to attempt to use a data structure that might be in the middle of being modified. In situations where a method on the object does not require synchronization, however, you will be synchronized anyway and the interactivity of the application will be reduced.

The other drawback to this approach is that it can increase contention and 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 the getting the synchronization correct. On the other hand, you get behavior that reduces interactivity and scalability. Different applications, or different parts of the same application, will choose 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.

 class tm  {  public void m()  {    Console.WriteLine("Thread {0} started",                        Thread.CurrentThread.GetHashCode());    Thread.Sleep(1000);    for(int i = 0; i < 10; i++)      Console.WriteLine(i);  }  class te  {    public void tue()    {      Console.WriteLine("Thread {0} started",                        Thread.CurrentThread.GetHashCode());      Exception e = new Exception("Thread Exception");      throw e;    }  }  class ThreadIsolation  {    static void Main(string[] args)    {      tm tt = new tm();      te tex = new te();      ThreadStart ts1 = new ThreadStart(tt.m);      ThreadStart ts2 = new ThreadStart(tex.tue);      Thread thread1 = new Thread(ts1);       Thread thread2 = new Thread(ts2);      Console.WriteLine("Thread {0} starting new threads.",      Thread.CurrentThread.GetHashCode());      thread1.Start();      thread2.Start();      Console.WriteLine("Thread {0} done.",                        Thread.CurrentThread.GetHashCode());    }  } 

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 others 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 F:\Work\ThreadIsolation.cs:line 23  0  1  2  3  4  5  6  7  8  9 

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

for RuBoard