"atomic" means the value will get set at once - other threads reading the value at the same time will either see the old value or the new value, nothing "in between". Reading/writings strings and ints is also atomic. However, reading/writing longs (or other value types >32 bit) is NOT atomic: you might end up reading 32 bits from the old value and the other 32 bits from the new value. But even though it's atomic, I'd suggest that you still put a lock around it. For example, in this code: Initialization:
int a = 0, b = 0, c = 0;
Thread 1:
a = 1;
if (b == 0) c++;
Thread 2:
b = 1;
if (a == 0) c++;
From a simple look at the code, it seems that c will be 0 or 1. c shouldn't be 2 because "c++" cannot run on both threads - it's incremented only if the other thread hasn't set its flag (a or b) yet. Writes and reads to a,b are atomic. The increment of c is not atomic (read and write of c are atomic, but the combination read-increment-write isn't atomic). But actually, it is possible for both "c++" to execute, so c could become 2! (though only on dual-core machines) It's also possible that both "c++" execute but c still becomes only 1. Both "c++" can execute because x86 CPUs are allowed to move the "read"-instruction from the if-condition above the write-instruction from the assignment above (or they might execute the read and write in parallel). I've tested this myself using hand-written assembler code, an Intel Core Duo WILL move reads above writes where possible! You'll have to insert a memory barrier instruction to prevent the CPU from doing that. In C#, the "volatile" keyword can be used for some kinds of memory barriers: volatile writes have release semantics, volatile reads have acquire semantics. That's sufficient for many cases of unsynchronized access to variables, but it doesn't help in the example I gave above - we need a full memory barrier there. -> If you access shared variables without locks, might have to insert a memory barriers to synchronize the memory between CPUs. It's extremely hard to get those right. So I would suggest that you keep it simple and always use a lock.
