thread-safety of primitive concurrent read and write

Question

• Simplified illustration below, how does .NET deal with such a situation?
• and if it would cause problems, would i have to lock/gate access to each and every field/property that might at times be written to + accessed from different threads?

A field somewhere

public class CrossRoads(){
    public int _timeouts;
}

A background thread writer

public void TimeIsUp(CrossRoads crossRoads){
    crossRoads._timeouts++;
}

Possibly at the same time, trying to read elsewhere

public void HowManyTimeOuts(CrossRoads crossRoads){
    int timeOuts = crossRoads._timeouts;
}

Answer 1

The simple answer is that the above code has the ability to cause problems if accessed simultaneously from multiple threads.

The .Net framework provides two solutions: interlocking and thread synchronization.

For simple data type manipulation (i.e. ints), interlocking using the Interlocked class will work correctly and is the recommended approach.

In fact, interlocked provides specific methods (Increment and Decrement) that make this process easy:

Add an IncrementCount method to your CrossRoads class:

public void IncrementCount() {
    Interlocked.Increment(ref _timeouts);
}

Then call this from your background worker:

public void TimeIsUp(CrossRoads crossRoads){
    crossRoads.IncrementCount();
}

The reading of the value, unless of a 64-bit value on a 32-bit OS, are atomic. See the Interlocked.Read method documentation for more detail.

For class objects or more complex operations, you will need to use thread synchronization locking (lock in C# or SyncLock in VB.Net).

This is accomplished by creating a static synchronization object at the level the lock is to be applied (for example, inside your class), obtaining a lock on that object, and performing (only) the necessary operations inside that lock:

    private static object SynchronizationObject = new Object();

    public void PerformSomeCriticalWork()
    {
        lock (SynchronizationObject)
        {
            // do some critical work
        }
    }

Answer 2

The good news is that reads and writes to ints are guaranteed to be atomic, so no torn values. However, it is not guaranteed to do a safe ++, and the read could potentially be cached in registers. There's also the issue of instruction re-ordering.

I would use:

Interlocked.Increment(ref crossroads._timeouts);

For the write, which will ensure no values are lost, and;

int timeouts = Interlocked.CompareExchange(ref crossroads._timeouts, 0, 0);

For the read, since this observes the same rules as the increment. Strictly speaking "volatile" is probably enough for the read, but it is so poorly understood that the Interlocked seems (IMO) safer. Either way, we're avoiding a lock.