C# volatile atomic type waited on and written to with different values by 2 threads - is this code threadsafe?

Question

With all previously discussed caveats about using "volatile" (vs full barriers/interlock*/lock) in mind, there are cases where "volatile" fits the bill. One such example is given in (the footnote of) the accepted answer to Volatile vs. Interlocked vs. lock.

As volatile doesn't prevent these kind of multithreading issues, what's it for? A good example is say you have 2 threads, one which always writes to a variable (say queueLength), and one which always reads from that same variable.

If queueLength is not volatile, thread A may write 5 times, but thread B may see those writes as being delayed (or even potentially in the wrong order).

A solution would be to lock, but you could also in this situation use volatile. This would ensure that thread B will always see the most up-to-date thing that thread A has written. Note however that this logic only works if you have writers who never read, and readers who never write, and if the thing you're writing is an atomic value.

As a variation to that scenario, suppose there is one variable of atomic type, and two threads A and B that each check for and assign mutually different values to the variable. In the simplest case, say that the variable is "volatile bool Do;". Thread A runs a loop that checks Do and, if false, sets it to true. Thread B runs its own loop which checks Do and, if true, sets it to false.

Is this scenario thread-safe in all senses of "safe"?

For an example, below is a (minimal, silly, unconscionable ;-)) code mockup.

volatile static bool Do;

static void ThdA()
{
    for(System.Random Rnd = new System.Random();;)
    {
        if((Rnd.Next() % 10010101) == 0)
        {
            while(Do); // wait for B to complete
            Do = true; // signal B to do something
        }
    }
}

static void ThdB()
{
    for(;;)
    {
        if(Do)
        {
            System.Console.Write("doing something\n");
            Do = false; // signal A that B done
        }
    }
}

[ EDIT ] Following some of the comments, I should clarify that my question is as much about saving half a fence in a very special case as it is about verifying my understanding of "volatile" semantics in this particular case. I am not suggesting any new/generic approach, and I am well aware of the ins and (mostly) outs of volatiles in general, as discussed elsewhere (http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-immutability-are-different-part-three.aspx, https://msdn.microsoft.com/en-us/magazine/jj883956.aspx, https: //software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ etc).

The question is strictly whether "volatile" is sufficient in the very narrow case described here. The obvious expectations of "safety" are:
- the program never deadlocks;
- neither thread reads stale values (for the code mockup, this translates to each "Do = true" in ThdA having a matching "Do = false" in ThdB).

Answer 1

Yes, this is fully thread safe.

The danger with these kinds of approaches is when the boolean changes between when you read it and when you test it (while(Do);), and between when you read it and when you write the updated version (Do = false), but your code is safe from the failures:

• in ThdA, if the variable changes between reading Do and testing it for the loop, you'll just loop one more time. But keep in mind the condition did fail if Do was false when reading it for testing in the loop, then turned true during the test. It just so happens that falling through sets it to true anyway in this case so it doesn't matter.

• in ThdB you have a similar case, it'll just loop one more time. I don't see how that part can fail, but adding more code can easily break it.

Answer 2

Here is a slight generalization of the original question. Suppose there is one variable of atomic type, and N threads ThdX with X = 0 ... N-1. The value of the atomic type indicates which thread "owns" it at a given point in time. Each thread checks the value and, if it detects that it is the "owner" thread, then it is allowed to change the value. The variable is not changed elsewhere.

(This reduces to the original question for N = 2 and a bi-valued bool instead of a multi-valued atomic type.)

Claim is that the program won't deadlock or hang (at least not due to threading issues with the volatile ;-)) and that each assignment to the volatile variable will be picked up by the target thread. The proposed arguments are in the comments inlined below.

static int N = <max-threads>;   // number of threads

volatile static int n;          // assuming n is in the range 0 ... N-1
                                // if n == X then ThdX can safely change n

static void ThdX() // individual thread functions for X = 0 ... N-1
{
    for(;;)
    {
        /* arbitrary code that doesn't change n */

        if(n == X)              //<--- volatile read
        {
            {
                // acquire fence guarantees that no other thread
                // can be inside this inner block at the same time
                // because - all reads get fresh values
                //         - only one thread can match the if condition
                //         - n does not change inside this inner block
                // and therefore no other thread can change n
                // before this thread executes the assignment below

                /* arbitrary code that doesn't change n */
            }

            n = <new-value> % N;  //<--- volatile write

            // release fence guarantees that other threads
            // will read the new value next time they check
        }

        /* arbitrary code that doesn't change n */
    }
}

For full generality, "int n" should be "T n" where T is an atomic type, and "n == X" should be "f(n) == X" where f(T n) is a function mapping a T value to a thread index, but neither changes the main points.