Writing Multithreaded Code

To create a new thread, first create a new Thread object, as shown in the following code:

static void Main(string[] args)
{
    Thread currentThread = Thread.CurrentThread;
    Thread workThread = new Thread(new ThreadStart(Work));
    
    

}
static void Work()
{
    Console.WriteLine("Hello");
}

The Thread constructor accepts a ThreadStart delegate as a parameter. This delegate is invoked when the thread is started and serves as the method where the thread begins execution. If the thread exits this method, the thread is terminated.

The method associated with the ThreadStart delegate can be static, as shown in the preceding example, or nonstatic. Using a nonstatic method enables the thread procedure to have access to instance variables that can serve as input, as shown in the following Worker class:

public class Worker
{
    protected string _message;
    public string Message
    {
        set { _message = value; }
        get { return _message; }
    }
    public void PrintMessage()
    {
        Console.WriteLine("Message from worker: {0}.", _message);
    }
}

When you create a new Thread object that uses the Worker class, the Worker instance is created and initialized first, as shown here:

static void Main(string[] args)
{
    Worker w = new Worker();
    w.Message = "Hello from the worker thread";
    Thread workerThread = new Thread(new ThreadStart(w.PrintMessage));
    
    

}

After a Thread object has been created, calling the Start method causes it to begin executing, as shown here:

workerThread.Start(); 

The thread will be scheduled to run by the operating system and will execute until it exits its ThreadStart method or until the thread is forced to stop by other means.

To suspend execution of a thread, call its Suspend method, as shown here:

workerThread.Suspend(); 

If the thread hasn’t been started or has finished executing, a ThreadStateException will be generated. The current state of a thread can be determined through the ThreadState property, which returns a ThreadState enumeration member. Table 10-1 describes the members of the ThreadState enumeration.

The ThreadState members listed in Table 10-1 are often combined. To determine whether a thread is in a particular state, use code such as the following to ensure that the thread is not in the Unstarted or Stopped state before attempting to suspend the thread:

if(IsThreadStarted(workerThread))
{
    workerThread.Suspend();
}

    

static bool IsThreadStarted(Thread aThread)
{
    bool result = ((aThread.ThreadState & ThreadState.Unstarted) != 0 
                && (aThread.ThreadState & ThreadState.Stopped) != 0);
    return result;
}

The ThreadState property can’t be used to absolutely determine a thread’s state in every case. Because threads run asynchronously, the thread state could easily change between the point in time when the thread state is sampled and the time when the state is tested. ThreadState can be used for testing obvious problems, however, such as an attempt to suspend a thread that has already been terminated.

The Resume method is used to restart a thread that’s currently suspended, like this:

workerThread.Resume();

The Interrupt method causes a thread to cut short any blocking behavior in which it’s currently involved, effectively waking up any threads in the WaitSleepJoin state. A ThreadInterruptedException exception is generated and must be handled if you want the thread to be able to continue execution after Interrupt has been called, as shown in the following code:

for(int loop = 0; loop < MaxIterations; ++loop)
{
    try
    {
        Thread.Sleep(SleepInterval);
        
    

    }
    catch(ThreadInterruptedException e)
    {
        Console.WriteLine("I've been interrupted");
    }
    
    

}

To terminate a thread, use the Abort method, as shown here:

workerThread.Abort();

When Abort is called for a thread, a ThreadAbortException exception is generated. Unlike the ThreadInterruptedException exception discussed earlier, you can’t stop this exception from terminating the current thread. The following code illustrates how the exception can be handled to clean up resources owned by the thread. The thread will always be terminated, however.

public void ThreadProc()
{
    try
    {
        Thread.Sleep(sleepInterval);
    }
    catch(ThreadAbortException e)
    {
        // Clean up resources.
    }
} 

The Join method is used to wait until a thread has terminated. This method blocks the current thread until the referenced thread has completed its work, as shown here:

workerThread.Join(); 

This code will wait unconditionally until the other thread completes its work. Two other overloads of the Join method enable you to specify a time-out period. These versions of Join return a bool that indicates the success or failure of the Join attempt. If a time-out occurs before the Join method succeeds, these methods return false. The following code uses a Join method with a time-out of 5 seconds:

workerThread.Join(5000); 

Every thread runs at a specific priority level, which can be retrieved or altered with the Priority property. The thread’s priority determines how the operating system will schedule the thread for execution, with higher priority threads always scheduled ahead of threads with lower priority. Values for the Priority property are taken from the ThreadPriority enumeration. The members of the ThreadPriority enumeration are listed here:

• Lowest

• BelowNormal

• Normal

• AboveNormal

• Highest

Threads initially have Normal priority. In the majority of cases, you shouldn’t need to change a thread’s priority. The operating system will always execute the thread with the highest priority, while sharing time equally among threads with the same priority. If a thread performs background work that can be deferred until all normal threads are idle, setting the priority to BelowNormal will prevent the worker thread from regularly preempting threads performing more important work. If a thread must be able to interrupt other threads to carry out its work, set the priority to AboveNormal or Highest.

The following code demonstrates the use of the Priority property to adjust a thread’s priority:

workerThread.Priority = ThreadPriority.BelowNormal; 

This example sets the thread’s priority level to BelowNormal, which means that this thread will be scheduled after the threads with Normal priority and before those with Lowest priority.

Threads that run in the runtime are designated as running in the foreground or background. A process will run as long as it includes at least one foreground thread. Background threads can perform the same work as foreground threads, but they’ll be terminated automatically when the last foreground thread terminates. The IsBackground property is used to get or set the background status for the thread, as shown here:

workerThread.IsBackground = true;

    

protected bool DumpThreadInfo(Thread aThread)
{
    bool background = aThread.IsBackground;
    
    

} 

The .NET Framework includes the Monitor class, which is part of the System.Threading namespace. The Monitor class is used to guard access to a reference variable or a section of code. A section of code that’s protected by the Monitor class is known as a critical section. As shown in Figure 10-1, a critical section can be accessed by a single thread at any given time.

Figure 10-1.

Threads blocked by a Monitor class guarding a critical section.

The Monitor class has only static methods. You never directly create an instance of the Monitor class, and because the class is sealed, other classes can’t inherit from it either. The Monitor class exposes the following two primary methods:

• Enter  Takes possession of a lock on an object passed as a parameter if the lock is available

• Exit  Releases possession of an object’s lock

The Monitor class is typically used as follows:

protected void UpdateMethod()
{
    Monitor.Enter(this);
    dangerousVariable++;
    Monitor.Exit(this);
} 

Before entering a region of code that’s been designated as a critical section, the thread makes a call to Monitor.Enter, passing an object reference as a parameter. If another thread has already called Monitor.Enter with the same object reference and hasn’t yet called Monitor.Exit, this thread will be blocked and won’t continue until the other thread has called Monitor.Exit.

When you use Monitor.Enter to take possession of an object-wide lock, you don’t protect any static members. To protect static type members, pass a typeof reference to the Monitor.Enter method, like this:

Monitor.Enter(typeof(Broken)); 

It’s very easy to implement coarse-grained synchronization for a method using the Monitor class. One problem with using Monitor to guard regions of your code is that you’re required to properly manage Monitor.Enter and Monitor.Exit pairs. For example, the following code is broken:

public void TakeALock()
{
    try
    {
        Monitor.Enter(this);
        ThrowAnException();
        Monitor.Exit(this);
    }
    catch
    {
        Console.WriteLine("Caught an exception");
    }
}
private void ThrowAnException()
{
    throw new InvalidOperationException("Bypass monitor code");
} 

When the exception flows through the TakeALock method, the call to Monitor.Exit is bypassed. No other thread can take possession of the object’s synchronization lock until the thread that owns the lock has called Monitor.Exit or until the thread that owns the lock has been destroyed.

To properly use the Monitor class in the presence of exceptions, you must write code such as the following:

public void ImprovedTakeALock()
{
    try
    {
        Monitor.Enter(this);
        ThrowAnException();
    }
    finally
    {
        Monitor.Exit(this);
    }
} 

In this code, the Monitor.Exit method is placed in a finally block, guaranteeing that the monitor will be released, even in the presence of exceptions.

	If you use the Monitor class directly, you should protect calls to Monitor.Exit by placing them in a finally block.

A simpler approach is to use the locking support that’s built into the C# language, as shown in the following code. The lock keyword is used to enact a coarse-grained lock on a reference variable, using a much simpler coding pattern than is required with the Monitor class. The most commonly used form of the lock keyword accepts a reference variable as a parameter and creates a guarded region.

public void SimpleLock()
{
    lock(this)
    {
        DoWork();
    }
} 

As with the Monitor class in the preceding section, you can lock static members for a class by locking the class type, like this:

public void SimpleLock()
{
    lock(typeof(Broken))
    {
        DoWork();
    }
} 

The lock keyword can be used to implement relatively coarse synchronization that relies on your ability to identify a single object that can be used for synchronization purposes. The .NET Framework also includes the following event and mutual exclusion classes that can be used to synchronize threads:

• ManualResetEvent  Provides an event object that’s signaled when a specific action occurs

• AutoResetEvent  Provides an automatically resetting event object that’s signaled when a specific action occurs

• Mutex  Provides interprocess resource synchronization

All the classes in this list are derived from the WaitHandle class, which generalizes the process of acquiring, releasing, and waiting for a synchronization object. Each class uses operating system resources to synchronize thread access. In keeping with the recommended design pattern for classes that have external references, the WaitHandle class (and the three derived classes) implements the IDisposable interface. This allows you to take advantage of the using statement when employing these classes, as shown here:

using(Mutex instanceMutex = new Mutex(false, mutexName))
{
    
    

} 

Every WaitHandle object is in one of the following two states:

• Signaled  Indicates that the WaitHandle object can be acquired by any thread.

• Not Signaled  Indicates that the WaitHandle object isn’t available for acquisition. Any threads attempting to acquire the object will be blocked until the synchronization object is signaled.

The WaitHandle class has the following three methods that are commonly used for synchronization in derived classes:

• WaitAll  Static method that blocks the calling thread until all handles in an array are signaled

• WaitAny  Static method that blocks the calling thread until any handle in an array is signaled

• WaitOne  Virtual method that blocks the calling thread until the current WaitHandle object is signaled

Each of these methods includes overloaded versions that allow you to specify a time limit for the wait attempt and specify whether to exit the synchronization domain before the wait.

AutoResetEvent automaticEvent = new AutoResetEvent(true);
ManualResetEvent manualEvent = new ManualResetEvent(false); 

public class EventApp
{
    protected ManualResetEvent initializationEvent = null;
    public EventApp()
    {
        initializationEvent = new ManualResetEvent(false);
    }
    
    static void Main()
    {
        Thread workerThread = new Thread(ThreadStart(this.Work));
        workerThread.Start();
        // Wait for initialization.
        initializationEvent.WaitOne();
        // Initialization complete.
        DoOtherWork();
        
    

   }

    protected void Work()
    {
        // Perform initialization.
        
    

        initializationEvent.Set();
        // Perform other work.
        
    

    }
}

Mutex instanceMutex = new Mutex(false, "MyApp.Initialization");

static void Main(string[] args)
{
    string mutexName = "MSPress.CSharpCoreRef.SingleInstance";
    using(Mutex instanceMutex = new Mutex(false, mutexName))
    {
        if(instanceMutex.WaitOne(1, true) == false)
        {
            Console.WriteLine("Another instance is executing");
            return;
        }
        Console.Write("Enter your name: ");
        string name = Console.ReadLine();
        Console.WriteLine("Hello, {0}.", name);
    }
} 

portMutex.ReleaseMutex();

One of the most common places where thread safety is needed is in collection objects. When multiple threads contend for access to a collection object, you must provide some type of synchronization or the collection will become corrupted. By default, collection classes in the .NET Framework aren’t synchronized. If multiple threads attempt to change the state of a collection object simultaneously, the object’s internal data structures won’t be synchronized and the behavior of the collection object will be unpredictable.

Leaving collections unsynchronized provides the best possible performance for single-threaded use, which is the most common scenario. If you’re writing multithreaded code, however, you’re not left out in the cold. The collection classes in the .NET Framework provide an easy way to create thread-safe collection objects.

As mentioned in Chapter 8, the ICollection interface includes the following two properties that are used for synchronization:

• IsSynchronized  Returns true if the collection is thread-safe

• SyncRoot  Returns an object that can be used for synchronization

The object returned by the SyncRoot property can be used with the lock statement to synchronize access to the collection object, like this:

lock(SyncRoot)

The following code implements a thread-safe wrapper around a Stack object by locking the object returned by the SyncRoot property for each access attempt:

public class SafeStack : Stack
{
    public SafeStack() :base() {}
    public SafeStack(ICollection col) :base(col) {}
    public SafeStack(int initialCapacity) :base(initialCapacity) {}

    public override object Pop()
    {
        lock(SyncRoot)
        {
            return base.Pop();
        }
    }

    public override object Peek()
    {
        lock(SyncRoot)
        {
            return base.Peek();
        }
    }

    public override void Push(object obj)
    {
        lock(SyncRoot)
        {
            base.Push(obj);
        }
    }

    public override object[] ToArray()
    {
        lock(SyncRoot)
        {
            return base.ToArray();
        }
    }

    public override int Count
    {
        get
        {
            lock(SyncRoot)
            {
                return base.Count;
            }
        }
    }

    public override void Clear()
    {
        lock(SyncRoot)
        {
            base.Clear();
        }
    }

    public override bool Contains(object obj)
    {
        lock(SyncRoot)
        {
            return base.Contains(obj);
        }
    }
}

In addition to the properties exposed by ICollection, most collection classes expose a static method named Synchronized that returns a thread-safe wrapper such as the one outlined in the preceding code. A collection object must be passed as a parameter to Synchronized. For example, to create an instance of a thread-safe Stack object such as the one shown in Figure 10-2, you use code such as the following:

Stack safeStack = Stack.Synchronized(new Stack());

Figure 10-2.

Synchronization wrappers, which enable safe access to collections.

If you need a collection object that’s fully synchronized so that any thread can be used to access any method or property, creating a thread-safe collection with the static Synchronized method is the simplest approach. If you need to occasionally synchronize a collection, or if you need to protect just a few methods for the collection, the collection’s SyncRoot property can be used to provide fine-grained synchronization, without the overhead of synchronization each time the collection is accessed.

Using the thread pool to queue asynchronous tasks is a great way to handle specific types of asynchronous work. For example, a work queue is perfectly suited for cases in which work must be performed but you don’t require notification when the work has been completed. Work items are added to a work queue, and the thread pool asynchronously removes items from the queue, as shown in Figure 10-3.

Figure 10-3.

The thread pool, which services items in the work queue.

To take advantage of the thread pool to execute work items, you must define a method that will be invoked by the thread pool to execute your work. This method, which will be bound to a WaitCallback delegate, is always declared as accepting an object parameter. Although the object parameter must be declared for every method associated with a WaitCallback delegate, it’s used only in scenarios in which arguments are provided to the method. One way to associate state information with your queued work item is to create a work object class that includes the necessary state as well as a method that’s invoked to carry out the work, as shown in the following code:

public class FibonacciWorkItem
{
    int _maxIterations;
    public FibonacciWorkItem(int maxIterations)
    {
        _maxIterations = maxIterations;
    }
    public void Calculate(object obj)
    {
        int x = 0;
        int y = 0;
        int fib = 0;
        for(int n = 0; n < _maxIterations; ++n)
        {
            Console.WriteLine(fib);
            x = y;
            if(fib == 0)
                y = 1;
            else
                y = fib;
            fib = x + y;
        }
    }
} 

This code declares a FibonacciWorkItem class that includes an upper limit for a Fibonacci sequence and a Calculate method that will be invoked by the thread pool. As the Fibonacci sequence is calculated, the result is written to the console.

To queue a FibonacciWorkItem object for execution by the thread pool, the static QueueUserWorkItem method is called, as shown here:

FibonacciWorkItem fwi = new FibonacciWorkItem(25);
ThreadPool.QueueUserWorkItem(new WaitCallback(fwi.Calculate)); 

Another approach is to use a separate object that contains state information and pass the object as a parameter when calling QueueUserWorkItem, as shown here:

class Fibonacci
{
    public static void Calculate(object obj)
    {
        int iterations = (int)obj;
        
    

    }
}

    

ThreadPool.QueueUserWorkItem(new WaitCallback(Fibonacci.Calculate), 25);

In this example, the Calculate method is stateless, and each invocation requires that necessary parameters be passed to it. This approach avoids the overhead of creating a new object to house the WaitCallback delegate and parameter state.

The thread pool also comes in handy when you’re waiting for WaitHandle objects to become signaled. A common, albeit inefficient, design pattern is to create a new thread that’s used to wait for a system handle to be signaled. The thread pool enables you to designate a method that will be invoked when a WaitHandle is signaled.

The RegisterWaitForSingleObject method is used to associate a Wait­Handle with a method to be invoked when the handle is signaled, as shown here:

string activePort = "2555";
int portTimeout = 5000;
RegisteredWaitHandle regHandle;
regHandle = ThreadPool.RegisterWaitForSingleObject(portOpenedEvent,
                               new WaitOrTimerCallback(PortOpened),
                               activePort,
                               portTimeout,
                               true);

The following five parameters are passed to RegisterWaitForSingleObject:

• WaitHandle  The WaitHandle object to be monitored.

• WaitOrTimerCallback  The delegate to be invoked when the WaitHandle object is signaled.

• object  An object passed as a parameter when the delegate is invoked.

• int  The length of time to wait for the WaitHandle object to be signaled before a time-out occurs. Pass a value of -1 to disable time supervision.

• bool  A Boolean value that’s set to true if the WaitHandle should be supervised only once. Pass false to enable continuous supervision.

A RegisteredWaitHandle object is returned from the call to RegisterWaitForSingleObject. To remove the association between the WaitHandle object and the callback delegate, call the RegisteredWaitHandle object’s Unregister method, like this:

regHandle.Unregister(portOpenedEvent); 

The callback method associated with the WaitHandle object is declared as shown in the following code. If a time-out occurs before the WaitHandle object is signaled, the timedOut parameter will be true.

protected void PortOpened(object state, bool timedOut)
{
    
    

} 

There are three additional overloaded versions of RegisterWaitForSingleObject, differing only in how the time-out period parameter is passed. Where the example discussed in this section uses an int value, these additional overloads enable the use of long, uint, or TimeSpan values.