C++/CLI Threading: Part II

Volatile Fields

The type qualifier volatile tells the compiler that no single thread controls all aspects of the object to which it is applied; specifically, one or more other threads might be reading from and/or writing to this variable asynchronously. Essentially, this qualifier forces the compiler to be less aggressive when performing optimization.

Consider the code fragment in Listing Two. In the absence of volatile, case 1 could safely be ignored because we immediately overwrite the value of i in case 2; however, given the volatile qualifier, the compiler must perform both store operations.

Listing Two

    volatile int i = 0;
/*1*/   i = 10;
/*2*/   i = 20;
/*3*/   if (i < 5 || i > 10) {
        // ...
    }

    int copy = i;
/*4*/   if (copy < 5 || copy > 10) {
        // ...
    }

In case 3, the compiler must generate code to fetch the value of i twice; however, its value might change between fetches. To make sure we are testing the same value, we have to write something like case 4 instead. By storing a snapshot of i in the nonvolatile variable copy, we can safely use the value of copy multiple times, knowing that its value cannot be changing "behind the scenes." By using volatile, we can avoid explicit synchronization for certain kinds of variable access.

Thread-Local Storage

When writing a multithreaded application, it can be useful to have variables that are specific to a particular thread. For example, consider the program in Listing Three.

Listing Three

using namespace System;
using namespace System::Threading;

public ref class ThreadX
{
/*1*/   int m1;
/*2*/   static int m2 = 20;
/*3*/   [ThreadStatic] static int m3 = 30;

public:
    ThreadX()
    {
        m1 = 10;
    }
    
    void TMain()
    {
        String^ threadName = Thread::CurrentThread->Name;
        
/*4*/       Monitor::Enter(ThreadX::typeid);
        for (int i = 1; i <= 5; ++i)
        {
            ++m1;
            ++m2;
            ++m3;
        }
        Console::WriteLine("Thread {0}: m1 = {1}, m2 = {2}, m3 = {3}",
            threadName, m1, m2, m3);
        Monitor::Exit(ThreadX::typeid);
    }
};

int main()
{
/*5*/   Thread::CurrentThread->Name = "t0";

    ThreadX^ o1 = gcnew ThreadX;
    Thread^ t1 = gcnew Thread(gcnew ThreadStart(o1, &ThreadX::TMain));
    t1->Name = "t1";

    ThreadX^ o2 = gcnew ThreadX;
    Thread^ t2 = gcnew Thread(gcnew ThreadStart(o2, &ThreadX::TMain));
    t2->Name = "t2";

    t1->Start();
/*6*/   (gcnew ThreadX)->TMain();
    t2->Start();
    t1->Join();
    t2->Join();
}

m1 is an instance field, so each instance of type ThreadX has its own copy, and that exists for the life of its parent object. On the other hand, m2 is a class field, so there is only one occurrence of it for the class, regardless of the number of instances of that class. In theory, this field exists until the application terminates. Neither of these fields is specific to a thread. With the appropriate constructs, both kinds of fields can be accessed by multiple threads.

Simply stated, thread-local storage is memory that is owned by a particular thread, and that memory is allocated when a new thread is created, and deallocated when that thread terminates. It combines the privacy of local variables with the persistence of static variables. A field is marked as being thread-local by attaching to it the attribute ThreadStatic, as shown in case 3 of Listing Three. Being a static field, m3 can have an initializer.

Function TMain is the entry point for new threads. This function simply increments the three fields m1, m2, and m3, five times each, and prints their current value. The lock block in case 4 makes sure that no other thread can concurrently access these fields while their values are being incremented or printed.

The primary thread sets its own name to t0 in case 5, and then creates and starts two threads. It also calls TMain directly, as a regular function rather than as part of thread creation and startup. One example of the output that can result is shown in Figure 2. (The only difference between the possible outputs is the order in which the threads do their incrementing and printing.)

Figure 2: One possible output of Listing Three.

Thread t0: m1 = 15, m2 = 25, m3 = 35
Thread t1: m1 = 15, m2 = 30, m3 = 5
Thread t2: m1 = 15, m2 = 35, m3 = 5

Each of the three threads has its own instance of m1, which is initialized to 10, so it is no surprise that each has the value 15 after being incremented five times. In the case of m2, all three threads share the same variable, so that one variable is incremented 15 times.

The threads t1 and t2 go through the thread-creation process, each getting its own version of m3. However, these thread-local variables take on their default value zero, rather than the initializer 30 shown in the source code. Beware! After being incremented five times, each has the value 5. Thread t0 exhibits different behavior. As we can see, this thread was not created by the same machinery as the other two threads. As a result, its m3 does take on the explicit initial value, 30. Also note that in case 6, TMain is being called as a regular function, not as part of the creation of a new thread.