Thread- Local Storage of Data in .NET

using System;
using System.Threading;

class ThreadLocalTest
{
    static ThreadLocal<string> greeting;
    ThreadLocal<int> numThreads = new ThreadLocal<int>(() => 1); // instance field

    static ThreadLocalTest()
    {
        greeting = new ThreadLocal<string>(() => "Greetings from the current thread");
    }

    static void Main()
    {
        Console.WriteLine(greeting.Value.Replace("current", "main"));
        greeting.Value = "Goodbye from the main thread";
        Thread t = new Thread(ThreadMethod);
        t.Start();
        t.Join();
        ThreadLocalTest tl = new ThreadLocalTest();
        Thread t2 = new Thread(tl.InstanceThreadMethod);
        t2.Start();
        t2.Join();
        Console.WriteLine("The number of current threads is now " + tl.numThreads.Value);
        Console.WriteLine(greeting.Value); // prints the main thread's copy which is still 1
        Console.ReadKey();
    }

    static void ThreadMethod()
    {
        Console.WriteLine(greeting.Value.Replace("current", "second"));
        greeting.Value = "Hello from the second thread"; // only affects the second thread's copy
        Console.WriteLine(greeting.Value);
    }

    void InstanceThreadMethod()
    {
        numThreads.Value++; // increment this thread's copy to 2
        Console.WriteLine("The number of current threads is " + this.numThreads.Value);
    }
}

The output is,

Notice that the ThreadLocal<T> constructor takes a Func<T> argument i.e. a delegate for a method with no parameters which returns a value of type T. Here we're passing it a compatible lambda expression.

Also, the thread-local variable is initialized 'lazily' i.e. it's not initialized until a thread first attempts to retrieve its Value property. You can check whether it's been initialized yet for the current thread with the IsValueCreated property.

Thread.SetData and Thread.GetData

These two static methods store and retrieve data for each thread in a local data store 'slot'. If you give this slot a name then it can be accessed throughout the application using that name, no matter where it was originally allocated.

This doesn't apply to unnamed slots which are only accessible if allocated within the current scope or exposed via a globally accessible variable.

Each thread in the application can store its own copy of the data within a single named or unnamed slot.

Here's a version of the earlier programs that use a named slot.

using System;
using System.Threading;

class ThreadNamedSlotTest
{
    static LocalDataStoreSlot greeting = Thread.AllocateNamedDataSlot("greeting");

    static void Main()
    {
        Thread.SetData(greeting, "Goodbye from the main thread");
        Thread t = new Thread(ThreadMethod);
        t.Start();
        t.Join();
        Console.WriteLine(Thread.GetData(greeting)); // prints the main thread's copy
        Thread.FreeNamedDataSlot("greeting"); // releases across all threads
        Console.ReadKey();
    }

    static void ThreadMethod()
    {
        Thread.SetData(greeting, "Hello from the second thread"); // only affects the second thread's copy
        Console.WriteLine(Thread.GetData(greeting));
        OtherClass oc = new OtherClass();
        oc.Print();
    }
}

class OtherClass
{
    public void Print()
    {
        Console.WriteLine("The next line is printed from other class ...");
        LocalDataStoreSlot greeting = Thread.GetNamedDataSlot("greeting");
        Console.WriteLine(Thread.GetData(greeting));
    }
}

The output is,

To use an unnamed slot, the declaration of the 'greeting' field would need to be changed.

static LocalDataStoreSlot greeting = Thread.AllocateDataSlot();

However, unless you made this field public, it would not then be accessible from OtherClass.

Using data slots has a couple of drawbacks.

• They're slower than the other two TLS approaches.
• The data is not strongly typed. Both the SetData and GetData methods take parameters of type Object.

Conclusion

Prior to the advent of .NET 4.0, thread-local storage was a little-known (and understood) aspect. NET's threading support even though the underlying mechanism is provided by the operating system itself.

However, it has assumed greater importance with the introduction of parallel programming support and the ThreadLocal<T> class in .NET 4.0. This is because it enables each thread to access its own copy of an object rather than a single shared object and thereby achieve thread safety without the need for locks.

The examples used in this article are also available in the accompanying download for anyone who would like to play around with the code.