iThink

In part 2, we looked at explicit threading support in great details and different ways that it can help create concurrency. In typical demo-ware fashion, the cost associated with thread creation is usually not mentioned. There is an explicit cost to create and destroy managed and native threads. Such cost will be amortized if the work these threads do far outweigh their creation cost. In simple terms, the longer that the threads spend on CPU calculating (not waiting for I/O), the smaller is the concern. If a large number of threads are created for small chunks of work, then the aggregate overhead will not be negligible.

There is a recourse in the .NET framework since the beginning, ThreadPool. Essentially, a pool of threads are created for reuse. Cost saving is achieved from reduced number of thread creation/destruction activities. When the work is done, threads in the pool do not die. They are released back to the pool for re-use. There is even a design pattern for this.

Something strange about the .NET 1.1 version of the documentation is that it says

The thread pool is created the first time you create an instance of the ThreadPool class.

However, despite that ThreadPool class is not declared as static, all its methods are static. Therefore, instantiating an object of ThreadPool is completely useless. Curiously, that sentence is purged in documentation for newer versions of .NET. Also, the ThreadPool class is now static. Some interesting characteristics

• There is no way to cancel a work item after it has been queued.
• There is one thread pool per process. The thread pool has a default size of 250 worker threads per available processor, and 1000 I/O completion threads.
• The number of threads in the thread pool can be changed by using the SetMaxThreads method.
• When all thread pool threads have been assigned to tasks, it creates new idle threads at 0.5 second intervals.
• The threads in the managed thread pool are background threads. That is, their IsBackground properties are true. This means that a ThreadPool thread will not keep an application running after all foreground threads have exited.
• When the thread pool reuses a thread, it does not clear the data in thread local storage or in fields that are marked with the ThreadStaticAttribute attribute.

I think the first point about no built-in support for cancellation is one reason for BackgroundWorker and TaskFactory but we’ll leave the discussion for the future.

Among the static methods, the main usage of ThreadPool will be through the QueueUserWorkItem methods, with and without a parameter, much like ThreadStart and ParameterizedThreadStart.

In the version with parameter to the ThreadPool pool.

public class HelloRunnable
{
    public static void run()
    {
        System.Console.WriteLine("Hello from a thread!");
    }

    public static void Main(string[] args)
    {
        System.Threading.ThreadPool.QueueUserWorkItem(run);
        System.Threading.ThreadPool.QueueUserWorkItem(new System.Threading.WaitCallback(run));
    }
}

As you can see, despite the documentation states that

Visual Basic users can omit the WaitCallback constructor, and simply use the AddressOf operator when passing the callback method to QueueUserWorkItem. Visual Basic automatically calls the correct delegate constructor.

It works in C# too. So there is no need to instantiate a WaitCallback if you don’t want to. This clumsy delegate requires an object parameter whichever version of the overloaded QueueUserWorkItem methods you call.

public class HelloRunnable
{
    public static void run(object state)
    {
        if(state != null)
            System.Console.WriteLine(state.ToString());
    }

    public static void Main(string[] args)
    {
        System.Threading.ThreadPool.QueueUserWorkItem(run);
        System.Threading.ThreadPool.QueueUserWorkItem(new System.Threading.WaitCallback(run));

        System.Threading.ThreadPool.QueueUserWorkItem(run, "Hello from a thread!");
        System.Threading.ThreadPool.QueueUserWorkItem(new System.Threading.WaitCallback(run), "Hello from a thread!");
    }
}

Part 1 introduced us to the basic of concurrent programming in .NET. In this series, we will move from .NET 1.0 to 4.0 and see how concurrency can be achieved using the evolving API. Today, we look at the most basic explicit threading class.

    public sealed class Thread : CriticalFinalizerObject, _Thread

Interestingly, the Thread class started to inherit from CriticalFinalizerObject and implement _Thread interface only since .NET framework 2.0. In .NET 1.0 and 1.1, it merely inherited from System.Object. The _Thread interface exposes the managed thread object to unmanaged code. Why this wasn’t the case before .NET 2.0 is beyond me. CriticalFinalizerObject is more interesting as it enforces the so-called Constrained Execution Region automatically in the derived class’s object finalizer (destructor in C#) code. Essentially, it means it will execute the finalizer even if the application domain is unloading or the thread is aborted. You can read all the glory details here.

When creating a new thread object, there are 4 flavors: a combination of whether the delegate to execute has parameters and whether there is a maximum stack size rule on the new thread. We will look at these options in detail.

• ThreadStart is a simple delegate that has no parameter and doesn’t have a return value. .NET delegates has no counterpart in Java. In C/C++, there is something called function pointer, which allows the caller to pass function objects around. Microsoft likes to claim that delegates are superior because they are type-safe. In details, all delegates are implemented as classes. Therefore, delegates are not first-class citizens in .NET. We will re-use the code from part 1 here.

public class HelloRunnable {
    public static void run() {
        System.Console.WriteLine("Hello from a thread!");
    }
    public static void Main(string [] args) {
        new System.Threading.Thread(run).Start();
    }
}

If you notice, there is no mention of any ThreadStart delegate in the code! This is a nice syntactic sugar introduced in .NET 2.0. Instead of instantiating an object of type ThreadStart like this

public class HelloRunnable
{
    public static void run()
    {
        System.Console.WriteLine("Hello from a thread!");
    }
    public static void Main(string[] args)
    {
        System.Threading.ThreadStart startDelegate = new System.Threading.ThreadStart(run);
        new System.Threading.Thread(startDelegate).Start();
    }
}

You get to pass in method name directly in the place of a delegate in the constructor.

• If you’ve thinking about the need to pass in parameters so that the new thread can use, ParameterizedThreadStart is your friend. It takes in an object as the parameter that gives you a lot of flexibility (e.g. you can pass in an entire hash table if you like) at the cost of type-safety. Since every classes derive from System.Object, the compiler won’t catch any error if you try to cast the parameter down to a more derived object. Maybe some sort of generic ParameterizedThreadStart with optional parameters (new in .NET 4.0) can help here.

public class HelloRunnable
{
    public static void run(object message)
    {
        System.Console.WriteLine(message);
    }
    public static void Main(string[] args)
    {
        System.Threading.ParameterizedThreadStart startDelegate = new System.Threading.ParameterizedThreadStart(run);
        new System.Threading.Thread(startDelegate).Start("Hello from a thread!");
    }
}

The lazy coder’s version without having to instantiate a ParameterizedthreadStart delegate is pretty much the same as the naked version.

public class HelloRunnable
{
    public static void run(object message)
    {
        System.Console.WriteLine(message);
    }
    public static void Main(string[] args)
    {
        new System.Threading.Thread(run).Start("Hello from a thread!");

    }
}

Something you might have asked. What if I want to return some values in these methods that run in a separate thread? Well, you can’t. The way ThreadStart and ParameterizedThreadStart delegates are designed explicitly prohibit return values. If you indeed want to do that, you have to think differently. In .NET, threading is provided via method calls and there lies the problem. There is no reason why you have to construct a method just to pass a piece of work to be run in a separate thread. In fact, once Lambda expressions are introduced in .NET 3.0 and in particular, the TaskFactory class in .NET 4.0, you can pass in Func<TResult> delegate that returns a value. Saving that, there are workarounds like this.

• At this point, we’re ready to talk about the mysterious second parameter in the constructors, maxStackSize. Each thread has a separate stack and it’s best not to use these overloaded constructors, as per documentation.

The sharp eyed readers will notice a subtle bug in all the above codes. Since the thread scheduler can execute these threads in any order as it sees fit. There is no guarantee that the child thread will complete by the time the parent thread exits. Now, this problem won’t exhibit as the parent thread in this case is the main thread, it exits and the process will exit. In Windows, a process won’t exit until all non-background threads it created exit. In other scenarios, you will have to explicitly wait for all threads to complete unless you’re ok with them being aborted unexpectedly.

You can wait for the child thread to complete in a few different ways.

public class HelloRunnable
{
    public static void run(object message)
    {
        System.Console.WriteLine(message);
    }
    public static void Main(string[] args)
    {
        var thread = new System.Threading.Thread(run);
        thread.Start("Hello from a thread!");
        thread.Join();
    }
}

If you prefer not to hold on to the Thread object, ManualResetEvent can come in handy.

public class HelloRunnable
{
    private static System.Threading.ManualResetEvent resetEvent = new System.Threading.ManualResetEvent(false);

    public static void run(object message)
    {
        System.Console.WriteLine(message);
        resetEvent.Set();
    }
    public static void Main(string[] args)
    {
        new System.Threading.Thread(run).Start("Hello from a thread!");
        resetEvent.WaitOne();
    }
}

It’s possible to use an anonymous delegate to avoid the need for the method definition. Whether this makes sense is debatable.

public class HelloRunnable
{
    private static System.Threading.AutoResetEvent resetEvent = new System.Threading.AutoResetEvent(false);

    public static void run(object message)
    {
        System.Console.WriteLine(message);
        resetEvent.Set();
    }
    public static void Main(string[] args)
    {
        new System.Threading.Thread(delegate (object message){
            System.Console.WriteLine(message);
            resetEvent.Set();}).Start("Hello from a thread!");
        resetEvent.WaitOne();
    }
}

Of course, in the extreme case, you can even use lambda expression like this.

public class HelloRunnable
{
    private static System.Threading.AutoResetEvent resetEvent = new System.Threading.AutoResetEvent(false);

    public static void run(object message)
    {
        System.Console.WriteLine(message);
        resetEvent.Set();
    }
    public static void Main(string[] args)
    {
        new System.Threading.Thread(message => {
            System.Console.WriteLine(message);
            resetEvent.Set();}).Start("Hello from a thread!");
        resetEvent.WaitOne();
    }
}

Programs that can be executed in parallel have recently gone mainstream due to the arrival of multicore processors. This isn’t a new technology as software that does heavy lifting have been doing this since time immemorial. Relational databases that deal with multiple read/write requests have always required parallelism. More recently, vertex and pixel shaders programs that render beautiful 3D graphics have also taken advantages of the availability of GPU processors.

So why now? The answer to that question, at least in my mind, is that Microsoft has suddenly stood behind concurrent programming in .NET steadfast. They have incorporated OpenMP in Visual Studio 2005 (just like how jQuery becomes supported so that average Joe doesn’t have to figure out all the details) but I haven’t comes across a single project that used OpenMP. With the advent of .NET 4.0, suddenly, you get 3 new options to write parallel code.

• Task Parallel Library
• Parallel LINQ
• Parallel Patterns Library (C++ based)

This is in addition to the existing libraries

• Concurrency and Coordination Runtime (.NET 2.0 as a separate download)
• Background Worker (.NET 2.0)
• ThreadPool (.NET 1.0)
• Explicit Threading (.NET 1.0)
• OpenMP (.NET 2.0 C++ based)

The sheer number of tools available shows that developers can take advantage of these at their preferred abstraction level. If necessary, they can drop all the way down to explicit threading and synchronize appropriately. Strangely, this is also where most programmers are first introduced to concurrent programming. In a way, my experience follows this path.

Explicit Threading –> ThreadPool –> Background Worker

As you might have guessed at this point, that path of learning concurrent programming is mainly aimed at UI-based codes. Typically, concurrent programming can achieve 2 main objectives:

1. Increase the responsiveness of UI
2. Reduce processing time via data/task parallelism

At its basic form, explicit threading provides the programmer a low level mechanism to introduce concurrency. It was introduced in .NET 1.0, it’s almost identical to Java threads. The only difference is the fact that .NET has a notion of delegates (typed function pointer) where Java doesn’t. For the start, I’m going to write the trivial multithreaded code without worrying about synchronization.

public class HelloRunnable implements Runnable {
    public void run() {
        System.out.println("Hello from a thread!");
    }
    public static void main(String args[]) {
        (new Thread(new HelloRunnable())).start();
    }
}

public class HelloRunnable {
    public static void run() {
        System.Console.WriteLine("Hello from a thread!");
    }
    public static void Main(string [] args) {
        new System.Threading.Thread(run).Start();
    }
}

As you can see, it’s remarkably simple to spin off a secondary thread to do some work. Incidentally, the comparable code written in C++ with Windows API is also similar.

#include <windows.h>
#include <stdio.h>

DWORD WINAPI run(LPVOID lpArg)
{
    fprintf(stderr,"Hello from a thread!\n");
    return NULL;
}
int main()
{
    int i;
    HANDLE hHandle;
    DWORD ThreadId;
    hHandle = CreateThread(0, 0, run, 0, 0, &ThreadId);
    if (hHandle == NULL) {
        fprintf(stderr,"Could not create Thread\n");
        exit(0);
    }
    WaitForSingleObject(hHandle,INFINITE);
    return 0;
}

P.S. There is a difference between concurrency and parallelism in folklore. They argue that you can have concurrent code that are not executed in parallel. For example, in all of the snippets above, they are all multithreaded.

• The thread that started the CLR which also executes the main method
• The thread that executes the run methond/function
• In the case of .NET, the finalizer thread that GC uses to clean up dead objects.

If they’re executed on a processor with the matching number of cores, then they’re said to execute in parellel. If there are fewer cores than the number of threads, then they’re said to execute concurrently. In this view, concurrency and parallelism has nothing to do with the source code and everything to do with the execution environment. This also makes the distinction not that interesting.