Question

Could you describe two methods of synchronizing multi-threaded write access performed
on a class member?

Please could any one help me what is this meant to do and what is the right answer.

Answer 1

When you change data in C#, something that looks like a single operation may be compiled into several instructions. Take the following class:

public class Number {
    private int a = 0;
    public void Add(int b) {
        a += b;
    }
}

When you build it, you get the following IL code:

IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  dup
// Pushes the value of the private variable 'a' onto the stack
IL_0003:  ldfld      int32 Simple.Number::a
// Pushes the value of the argument 'b' onto the stack
IL_0008:  ldarg.1
// Adds the top two values of the stack together
IL_0009:  add
// Sets 'a' to the value on top of the stack
IL_000a:  stfld      int32 Simple.Number::a
IL_000f:  ret

Now, say you have a Number object and two threads call its Add method like this:

number.Add(2); // Thread 1
number.Add(3); // Thread 2

If you want the result to be 5 (0 + 2 + 3), there’s a problem. You don’t know when these threads will execute their instructions. Both threads could execute IL_0003 (pushing zero onto the stack) before either executes IL_000a (actually changing the member variable) and you get this:

a = 0 + 2; // Thread 1
a = 0 + 3; // Thread 2

The last thread to finish ‘wins’ and at the end of the process, a is 2 or 3 instead of 5.

So you have to make sure that one complete set of instructions finishes before the other set. To do that, you can:

1) Lock access to the class member while it’s being written, using one of the many .NET synchronization primitives (like lock, Mutex, ReaderWriterLockSlim, etc.) so that only one thread can work on it at a time.

2) Push write operations into a queue and process that queue with a single thread. As Thorarin points out, you still have to synchronize access to the queue if it isn’t thread-safe, but it’s worth it for complex write operations.

There are other techniques. Some (like Interlocked) are limited to particular data types, and there are even more (like the ones discussed in Non-blocking synchronization and Part 4 of Joseph Albahari’s Threading in C#), though they are more complex: approach them with caution.