Volatile vs Interlocked vs lock

Question

Let s say that a class has a public int counter field that is accessed by multiple threads  This int is only incremented or decremented   To increment this field  which approach should be used  and why    lock this locker  this counter     Interlocked Increment ref this counter    Change the access modifier of counter to public volatile    Now that I ve discovered volatile  I ve been removing many lock statements and the use of Interlocked  But is there a reason not to do this

User · Accepted Answer

Worst  won t actually work   Change the access modifier of counter to public volatile  As other people have mentioned  this on its own isn t actually safe at all  The point of volatile is that multiple threads running on multiple CPUs can and will cache data and re-order instructions  If it is not volatile  and CPU A increments a value  then CPU B may not actually see that incremented value until some time later  which may cause problems  If it is volatile  this just ensures the two CPUs see the same data at the same time  It doesn t stop them at all from interleaving their reads and write operations which is the problem you are trying to avoid  Second Best   lock this locker  this counter     This is safe to do  provided you remember to lock everywhere else that you access this counter   It prevents any other threads from executing any other code which is guarded by locker  Using locks also  prevents the multi-CPU reordering problems as above  which is great  The problem is  locking is slow  and if you re-use the locker in some other place which is not really related then you can end up blocking your other threads for no reason  Best  Interlocked Increment ref this counter    This is safe  as it effectively does the read  increment  and write in  one hit  which can t be interrupted  Because of this  it won t affect any other code  and you don t need to remember to lock elsewhere either  It s also very fast  as MSDN says  on modern CPUs  this is often literally a single CPU instruction    I m not entirely sure however if it gets around other CPUs reordering things  or if you also need to combine volatile with the increment  InterlockedNotes   INTERLOCKED METHODS ARE CONCURRENTLY SAFE ON ANY NUMBER OF COREs OR CPUs  Interlocked methods apply a full fence around instructions they execute  so reordering does not happen  Interlocked methods do not need or even do not support access to a volatile field  as volatile is placed a half fence around operations on given field and interlocked is using the full fence   Footnote  What volatile is actually good for  As volatile doesn t prevent these kinds of multithreading issues  what s it for  A good example is saying you have two 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 five 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 use volatile in this situation  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 soon as you do a single read-modify-write  you need to go to Interlocked operations or use a Lock

User · Answer

volatile  does not replace Interlocked Increment  It just makes sure that the variable is not cached  but used directly   Incrementing a variable requires actually three operations     read increment write   Interlocked Increment performs all three parts as a single atomic operation

User · Answer

I would like to add to mentioned in the other answers the difference between volatile  Interlocked  and lock   The volatile keyword can be applied to fields of these types    Reference types  Pointer types  in an unsafe context   Note that although the pointer itself can be volatile  the object that it points to cannot  In other words  you cannot declare a  pointer  to be  volatile   Simple types such as sbyte  byte  short  ushort  int  uint  char  float  and bool  An enum type with one of the following base types  byte  sbyte  short  ushort  int  or uint  Generic type parameters known to be reference types  IntPtr and UIntPtr    Other types  including double and long  cannot be marked  volatile  because reads and writes to fields of those types cannot be guaranteed to be atomic  To protect multi-threaded access to those types of fields  use the Interlocked class members or protect access using the lock statement

User · Answer

lock      works  but may block a thread  and could cause deadlock if other code is using the same locks in an incompatible way   Interlocked   is the correct way to do it     much less overhead as modern CPUs support this as a primitive   volatile on its own is not correct   A thread attempting to retrieve and then write back a modified value could still conflict with another thread doing the same

User · Answer

I did some test to see how the theory actually works  kennethxu blogspot com 2009 05 interlocked-vs-monitor-performance html  My test was more focused on CompareExchnage but the result for Increment is similar  Interlocked is not necessary faster in multi-cpu environment  Here is the test result for Increment on a 2 years old 16 CPU server  Bare in mind that the test also involves the safe read after increase  which is typical in real world   D   gt InterlockVsMonitor exe 16 Using 16 threads            InterlockAtomic RunIncrement          ns     8355 Average    8302 Minimal    8409 Maxmial     MonitorVolatileAtomic RunIncrement          ns     7077 Average    6843 Minimal    7243 Maxmial  D   gt InterlockVsMonitor exe 4 Using 4 threads            InterlockAtomic RunIncrement          ns     4319 Average    4319 Minimal    4321 Maxmial     MonitorVolatileAtomic RunIncrement          ns      933 Average     802 Minimal    1018 Maxmial

User · Answer

EDIT  As noted in comments  these days I m happy to use Interlocked for the cases of a single variable where it s obviously okay  When it gets more complicated  I ll still revert to locking     Using volatile won t help when you need to increment - because the read and the write are separate instructions  Another thread could change the value after you ve read but before you write back   Personally I almost always just lock - it s easier to get right in a way which is obviously right than either volatility or Interlocked Increment  As far as I m concerned  lock-free multi-threading is for real threading experts  of which I m not one  If Joe Duffy and his team build nice libraries which will parallelise things without as much locking as something I d build  that s fabulous  and I ll use it in a heartbeat - but when I m doing the threading myself  I try to keep it simple

User · Answer

Interlocked functions do not lock   They are atomic  meaning that they can complete without the possibility of a context switch during increment   So there is no chance of deadlock or wait   I would say that you should always prefer it to a lock and increment   Volatile is useful if you need writes in one thread to be read in another  and if you want the optimizer to not reorder operations on a variable  because things are happening in another thread that the optimizer doesn t know about    It s an orthogonal choice to how you increment   This is a really good article if you want to read more about lock-free code  and the right way to approach writing it  http   www ddj com hpc-high-performance-computing 210604448

User · Answer

Either lock or interlocked increment is what you are looking for   Volatile is definitely not what you re after - it simply tells the compiler to treat the variable as always changing even if the current code path allows the compiler to optimize a read from memory otherwise   e g   while  m Var        if m Var is set to false in another thread but it s not declared as volatile  the compiler is free to make it an infinite loop  but doesn t mean it always will  by making it check against a CPU register  e g  EAX because that was what m Var was fetched into from the very beginning  instead of issuing another read to the memory location of m Var  this may be cached - we don t know and don t care and that s the point of cache coherency of x86 x64   All the posts earlier by others who mentioned instruction reordering simply show they don t understand x86 x64 architectures  Volatile does not issue read write barriers as implied by the earlier posts saying  it prevents reordering   In fact  thanks again to MESI protocol  we are guaranteed the result we read is always the same across CPUs regardless of whether the actual results have been retired to physical memory or simply reside in the local CPU s cache  I won t go too far into the details of this but rest assured that if this goes wrong  Intel AMD would likely issue a processor recall  This also means that we do not have to care about out of order execution etc  Results are always guaranteed to retire in order - otherwise we are stuffed   With Interlocked Increment  the processor needs to go out  fetch the value from the address given  then increment and write it back -- all that while having exclusive ownership of the entire cache line  lock xadd  to make sure no other processors can modify its value   With volatile  you ll still end up with just 1 instruction  assuming the JIT is efficient as it should  - inc dword ptr  m Var   However  the processor  cpuA  doesn t ask for exclusive ownership of the cache line while doing all it did with the interlocked version  As you can imagine  this means other processors could write an updated value back to m Var after it s been read by cpuA  So instead of now having incremented the value twice  you end up with just once   Hope this clears up the issue   For more info  see  Understand the Impact of Low-Lock Techniques in Multithreaded Apps  - http   msdn microsoft com en-au magazine cc163715 aspx  p s  What prompted this very late reply  All the replies were so blatantly incorrect  especially the one marked as answer  in their explanation I just had to clear it up for anyone else reading this  shrugs  p p s  I m assuming that the target is x86 x64 and not IA64  it has a different memory model   Note that Microsoft s ECMA specs is screwed up in that it specifies the weakest memory model instead of the strongest one  it s always better to specify against the strongest memory model so it is consistent across platforms - otherwise code that would run 24-7 on x86 x64 may not run at all on IA64 although Intel has implemented similarly strong memory model for IA64  - Microsoft admitted this themselves - http   blogs msdn com b cbrumme archive 2003 05 17 51445 aspx

User · Answer

I second Jon Skeet s answer and want to add the following links for everyone who want to know more about  volatile  and Interlocked     Atomicity  volatility and immutability are different  part one -  Eric Lippert s Fabulous Adventures In Coding   Atomicity  volatility and immutability are different  part two   Atomicity  volatility and immutability are different  part three  Sayonara Volatile -  Wayback Machine snapshot of Joe Duffy s Weblog as it appeared in 2012

[c#] Volatile vs. Interlocked vs. lock

Worst (won't actually work)

Second Best:

Best

Footnote: What volatile is actually good for.

Examples related to c#

Examples related to multithreading

Examples related to locking

Examples related to volatile

Examples related to interlocked