In Java, threading operations are centered on the java.lang.Thread class. .NET has the equivalent System.Threading.Thread class. Unlike Java, .NET doesn’t allow classes to be derived from Thread, so creating a thread is more like the use of the Java Runnable interface, where the code to be executed is contained in another class. In .NET, threads are created by passing an instance of the ThreadStart delegate to the constructor of a new Thread instance. Here’s a simple threading example in Java using the Runnable interface:

public class Example implements Runnable {

    public void run() {
        for (int i = 0; i < 10; i++) {
            System.out.println("Counter: " + i);
        }
    }

    public Example() throws Exception {
        Thread x_thread = new Thread(this);
        x_thread.start();
    }
}

The Example class implements the Runnable interface, which is passed as a parameter to a new instance of Thread. When the Thread is started, it calls the Example.run method.

Here’s the equivalent in C#:

using System;
using System.Threading;

namespace Example {

    class Example {

        public void run() {
            for (int i = 0; i < 10; i++) {
                Console.WriteLine("Counter " + i);
            }
        }

        public Example() {
            Thread x_thread = new Thread(new ThreadStart(run));
            x_thread.Start();
        }
    }
}

Key points worth highlighting include the following:

Another difference between .NET and Java is that the methods suspend and resume are available for use in a C# application. In Java, these methods (and the stop method) have been deprecated because they are considered inherently unsafe. While the same potential problems with the Suspend and Resume methods exist in a .NET application, Microsoft decided not to eliminate this functionality but rather to allow developers to take their own precautions.

It’s recommended that Java threads be controlled by modifying a variable that is periodically checked during execution, a process known as polling. This is commonly achieved by setting the thread reference to null and checking that the reference matches the current thread during iteration:

private volatile Thread o_blinker;

public void stop() {
    o_blinker = null;
}

public void run() {
    Thread x_this_thread = Thread.currentThread();
    while (o_blinker == x_this_thread) {
        // perform some operations
    }
}

Besides reducing flexibility and introducing complexity, this approach has one major consequence: for methods that take a long time to complete, the responsiveness of the thread is dependent on the frequency with which the thread reference is checked. The programmer has to decide between checking the state frequently and accepting that the call to stop might not result in the thread being halted immediately.

By contrast, .NET supports almost immediate thread control using the Suspend and Resume methods. These methods work as their names indicate. Resuming a thread that has been suspended causes execution to continue from the point at which it stopped. Watch out for the exceptions that can be thrown; it’s easy to forget about them since C# doesn’t enforce declaring exceptions on method signatures.

Both methods will throw a ThreadStateException if the thread hasn’t been started or because the thread is dead. In addition, Resume will throw this exception if the thread hasn’t been suspended. Checking the thread state before making one of these calls can help minimize these exceptions. See the Thread States section later in this chapter.

Also note that these calls will throw a SecurityException if the caller doesn’t have the required permission. See Chapter 17, for more information on security.

The .NET Thread class provides an overloaded method, named Abort, for stopping the execution of a thread. Calling this method causes a ThreadAbort-Exception to be raised in the method that was passed to the ThreadStart instance when the thread was instantiated.

There are two overloads on this method:

public void Abort();
public void Abort(object);

The first version takes no parameters, causes the exception to be thrown, and begins the process of terminating the thread. The second overload takes an object as an argument, which is made available through the exception, and can be used to tidy up.

It’s possible to catch a ThreadAbortException, but this doesn’t prevent the thread from being killed. The exception will be thrown again at the end of the try...catch block, but only after any finally blocks have been executed. This presents an opportunity to clean up any incomplete state and to ensure that any resources are correctly released.

The following fragment shows how this may be done:

public void run() {
    try {
        while (true) {
            try {
                // do some important operation that can result
                // in state problems if stopped suddenly
            } catch (ThreadAbortException) {
                Console.WriteLine("Got inner abort exception.");
            } finally {
                Console.WriteLine("Tidy up.");
            }
        }
    } catch (ThreadAbortException) {
        Console.WriteLine("Got outer abort exception.");
    }
}

The results of passing a method into a ThreadStart delegate and then calling Abort on the running thread are shown below:

Got inner abort exception.
Tidy up.
Got outer abort exception.

The opportunity to tidy up occurs at each point in the code where the ThreadAbortException is caught. If the exception is not caught, it will unwind up the stack to the thread class instance and will not be seen again. The try...catch...finally block is not required since there is no state to maintain and notifications about thread deaths are not required.

Although calling Abort seems neater and more intuitive than the Java approach detailed earlier, there is no way to determine where the exception will be thrown. It falls to the developer to ensure that no unusual state is left behind if, for example, the exception is thrown during iteration.

Although calls to Abort usually result in threads being stopped, the CLR makes no guarantees. An unbounded computation (one that will never complete) can be started in the catch block for ThreadAbortException. For this reason, it’s important to use the catch block only as intended and not to perform further calculations. If the caller of the Abort method needs to ensure that the thread has stopped, the Join method can be used, which will block until the thread has been unraveled and stopped.

Another reason that a thread might not stop is that Thread.ResetAbort might be called in the catch statement. This doesn’t stop the exception from being thrown again but does prevent the thread from terminating. This method should be used with care because any other threads blocking through the Join method won’t return as expected. Time should be taken to consider why a thread should refuse to die when asked.

We have seen the Abort and ResetAbort methods used to try to build a cleaner version of the Java approach to stopping threads, by which an internal flag is used to cause the thread to stop naturally after the current iteration. This approach is problematic because it’s impossible to continue the current iteration correctly without knowing where the exception is thrown. If it’s important that a thread finish the current iteration before stopping, we recommend using the Java approach, although other threads might still call the Abort method and cause unexpected results.

Finally, if a thread is blocking because a call has been made to Wait, the ThreadAbortException won’t be raised until the thread returns from the call or is interrupted, meaning that the target thread won’t be stopped immediately. It’s possible to determine in advance whether this is likely to be the case by examining the state of the thread, which is discussed later in this chapter in the Thread States section.

Thread priorities in .NET are handled in much the same way as in Java. The .NET Thread class has a property named Priority, which controls the thread’s priority level using the enumeration System.Threading.ThreadPriority. Five priority levels are defined in .NET, vs. 10 in Java, and they are (in descending priority): Highest, AboveNormal, Normal, BelowNormal, and Lowest. By default, threads are created with Normal priority.

As with Java, the scheduling of threads is driven by the underlying operating system. The operating system is not required to honor thread priorities.

There is no direct equivalent of the Java yield method in .NET. To ensure that threads of equal priority execute in a .NET application, use Thread.Sleep(0).

.NET threads have a defined set of states that demarcate their life cycle. These states are defined in the System.Threading.ThreadState enumeration and are described in Table 13-1.

These states are accessible through the read-only Thread.ThreadState property. Threads can be in more than one state, so it’s important to check the state carefully. For example, if a thread is blocked because of a call to the Monitor.Wait class and another thread calls Abort, the blocked thread will be in both the WaitSleepJoin and AbortRequested states. (See the Synchronization section later in this chapter for an explanation of the Monitor.Wait class.) When the blocked thread returns from the Wait call or is interrupted, the state will be just AbortRequested and the ThreadAbortException will be thrown, leading to an Aborted state.

Key points worth highlighting include the following:

Table 13-2 lists actions and the effect they have on thread state.

When using the thread states, bear in mind that they can change quickly and might be altered before subsequent calls are made. Just because the thread has a state of Suspended when checked doesn’t necessarily mean that it will remain that way for long before another thread calls Resume. For this reason, it’s important to check for the possible exceptions when using the thread calls.

Both Java and .NET provide similar means to interrupt a thread that is blocking. In .NET, a thread is blocked when it’s sleeping (via the Sleep method), waiting for another thread to end (through the Join method), waiting to obtain access to a synchronized code block, or waiting to be signaled by an event.

There are two significant differences when interrupting a thread with .NET. The first is that since C# doesn’t require exceptions to be declared in the way that Java does, it’s easy to miss instances of ThreadInterruptedException—the .NET equivalent of the Java InterruptedException—being thrown. These exceptions roll up the call stack of the target thread and can disappear without a trace. If threading code shouldn’t terminate when the thread is interrupted, it’s vital that these exceptions be caught.

The second difference is more dangerous. With Java, calling Interrupt on a thread that isn’t blocking has no effect. In .NET, however, calling Interrupt on a thread that isn’t blocking will cause the thread to be interrupted the next time it blocks. This means that calls to interrupt a thread can have unexpected results long after Interrupt is called, creating a problem that can be difficult to track down. We advise caution in the use of this method in .NET.

Since version 1.2, Java has provided the ThreadLocal class, representing a specialized variable type in which each thread that sets or gets the value modifies its own independent copy of the variable. .NET makes some broadly similar features available, but in contrast with Java, the calls that drive these features are integrated directly into the Thread class and are based on the idea of data slots.

There is also a metadata annotation using attributes that allows for a similar effect without directly using the Thread class.

LocalDataStoreSlot x_named_slot =
    Thread.AllocateNamedDataSlot("my slot");
LocalDataStoreSlot x_unnamed_slot = Thread.AllocateDataSlot();

Thread.SetData(x_named_slot, "data");
Thread.SetData(x_unnamed_slot, "data");

// get the data
object x_unnamed_data = Thread.GetData(x_unnamed_slot);
object x_named_data =
    Thread.GetData(Thread.GetNamedDataSlot("my slot"));

[ThreadStatic] static int S_COUNTER;

Many threads sleep for most of the time, waking periodically to perform some system or background task—for example, clearing a cache or updating a window. Creating threads consumes system resources, so a common approach to addressing this issue is to provide timers that will signal a callback after a given time period to perform the background task. The advantage of this approach is that the operating system or runtime platform can optimize the way that these signals are managed and use fewer resources to attain the same effect as a pool of programmer-created threads.

.NET provides three different timers to programmers: System.Threading.Timer, System.Timers.Timer, and System.Windows.Forms.Timer. Broadly speaking, the Forms.Timer class should be used only for UI applications, as its precision is limited to around 55 ms; for high-performance applications, this level of granularity can be a problem.

The System.Threading.Timer class uses the ThreadPool class, discussed in The ThreadPool Class section later in this chapter, to periodically call delegates. This approach is more accurate than the Forms.Timer approach and is suitable for general use.

The System.Timers.Timer class provides the greatest accuracy and flexibility. Time ticks are generated by the operating system and place the lowest demand on system resources.

We’ll ignore the Forms.Timer class—also known as the Windows timer—and focus on the more accurate implementations, which are useful in server-side programming.

class ThreadTimer {
    Timer o_timer;

    public ThreadTimer() {
        // create the timer
        o_timer = new Timer(new TimerCallback(TimerCallbackHandler),
            null, 1000, 2000);
    }

    void TimerCallbackHandler(object p_state) {
        DateTime x_now = DateTime.Now;
        Console.WriteLine("Timer Called: {0}:{1}:{2} ", x_now.Hour,
            x_now.Minute, x_now.Second);
    }
}

Timer Called: 14:23:10
Timer Called: 14:23:12
Timer Called: 14:23:14
Timer Called: 14:23:16

class TimerExample {

    public TimerExample() {
        System.Timers.Timer x_timer = new System.Timers.Timer(2000);
        x_timer.Elapsed += new ElapsedEventHandler(onElapsed);
        x_timer.AutoReset = true;
        x_timer.Enabled = true;
    }

    public static void onElapsed(
        object p_source,
        ElapsedEventArgs p_event) {

        DateTime x_now = DateTime.Now;
        Console.WriteLine("Timer Called: {0}:{1}:{2} ",
            x_now.Hour, x_now.Minute, x_now.Second);
    }
}

Table 13-3 summarizes the basic threading members for Java and .NET.