Interlocked and volatile

Question

I have a variable which I am using to represent state. It can be read and written to from multiple threads.

I am using Interlocked.Exchange and Interlocked.CompareExchange to change it. However I am reading it from multiple threads.

I know that volatile can be used to make sure the variable is not cached locally but always reads directly from memory.

However if I set the variable to volatile then it generates a warning about using volatile and passing using ref to the Interlocked methods.

I want to ensure that each thread is reading the most recent value of the variable and not some cached version, but I can't use volatile.

There is a Interlocked.Read but it is for 64 bit types and is not available on the compact framework. The documentation for it says that it is not needed for 32 bit types as they are already performed in a single operation.

There are statements made across the internet that you don't need volatile if you are using the Interlocked methods for all your access. However you can't read a 32 bit variable using the Interlocked methods, so there is no way you can use Interlocked methods for all your access.

Is there some way to accomplish the thread safe read and write of my variable without using lock?

Answer 1

You can safely disregard that warning when you're using Interlocked.Xxx functions (see this question), because they always do volatile operations. So a volatile variable is perfectly OK for shared state. If you want to get rid of the warning at all costs, you actually can do an interlocked read with Interlocked.CompareExchange (ref counter, 0, 0).

Edit: Actually, you need volatile on your state variable only if you are going to write to it directly (i.e. not using Interlocked.Xxx). As jerryjvl mentioned, reads of a variable updated with an interlocked (or volatile) operation will use the most recent value.

Answer 2

Interlocked operations and volatile are not really supposed to be used at the same time. The reason you get a warning is because it (almost?) always indicates you have misunderstood what you are doing.

Over-simplifying and paraphrasing:
volatile indicates that every read operation needs to re-read from memory because there might be other threads updating the variable. When applied to a field that can be read/written atomically by the architecture you are running on, this should be all you need to do unless you are using long/ulong, most other types can be read/written atomically.

When a field is not marked volatile, you can use Interlocked operations to make a similar guarantee, because it causes the cache to be flushed so that the update will be visible to all other processors... this has the benefit that you put the overhead on the update rather than the read.

Which of these two approaches performs best depends on what exactly you are doing. And this explanation is a gross over-simplification. But it should be clear from this that doing both at the same time is pointless.