Question

This question keeps haunting me: in a multithreaded/multiprocessor environment – is it necessary to use explicit locks to synchronize access to shared variables?

Here is a scenario: I have a global variable pointing to a shared object. When an instance of the object is created, the reference to it is placed in the variable and becomes accessible to other threads/processors.

The object itself is immutable – once created it never changes, because of this multiple threads can access it without any additional synchronization.

Once in a while I need to update the object. I do it be creating a new instance of the object on the side and then place a reference to the new object in the global variable.

So here is the question: Can I consider replacing the reference to be an atomic operation. In other words does the variable always have a valid reference to my object – either the old one or the new one?

Answer 1

is it necessary to use explicit locks to synchronize access to shared variables?

Necessary? No. A good idea? Yes. Low-lock techniques are very hard to get right and rarely justified. Remember, a lock is slow when contested; if your locks are being contested, fix the problem that is causing them to be contested, rather than going to a low-lock solution.

The object itself is immutable – once created it never changes, because of this multiple threads can access it without any additional synchronization.

Awesome.

Once in a while I need to update the object. I do it be creating a new instance of the object on the side and then place a reference to the new object in the global variable.

So here is the question: Can I consider replacing the reference to be an atomic operation. In other words does the variable always have a valid reference to my object – either the old one or the new one?

Yes. The C# specification guarantees that operations on references are atomic. However atomicity is just one small part of thread safety. Atomicity merely guarantees that every time you look at the variable, you get a valid reference out of it. It does not guarantee that every time you look at the variable you get the current reference out of it. Nor does it guarantee that any two threads see the same sequence of changes in the same order. Nor does it guarantee that two atomic updates to two different variables are seen in the order they happened on every thread. Atomicity guarantees you practically nothing, and it might not guarantee you enough to make your program work the way you think it should.

My advice: if you can avoid accessing this variable on multiple threads, do so. If you cannot avoid it, put locks around it. Only if you find that for performance reasons the locks are too slow and you cannot eliminate enough contention should you consider going to dangerous low-lock techniques like making the variable volatile, using interlocked exchanges, and so on.