Threads and shared basic datatypes
-
Is it quaranteed that operations to basic datatypes are atomic? Or can I safely do the following:
INT g_i; void main() { ... // Manipulate g_i also here... ... } DWORD WINAPI ThreadProc(LPVOID lpParameter) { ... g_i++; // Is this safe? ... }I started wondering this after noticed functions such asInterlockedIncrementin MSDN. Where are these functions used? I have always thought that individual increase statement as above are always atomic.. Cohen -
Is it quaranteed that operations to basic datatypes are atomic? Or can I safely do the following:
INT g_i; void main() { ... // Manipulate g_i also here... ... } DWORD WINAPI ThreadProc(LPVOID lpParameter) { ... g_i++; // Is this safe? ... }I started wondering this after noticed functions such asInterlockedIncrementin MSDN. Where are these functions used? I have always thought that individual increase statement as above are always atomic.. Cohen -
Is it quaranteed that operations to basic datatypes are atomic? Or can I safely do the following:
INT g_i; void main() { ... // Manipulate g_i also here... ... } DWORD WINAPI ThreadProc(LPVOID lpParameter) { ... g_i++; // Is this safe? ... }I started wondering this after noticed functions such asInterlockedIncrementin MSDN. Where are these functions used? I have always thought that individual increase statement as above are always atomic.. CohenNo. The assembly opperation is something like this: (on some silly machine that I just made up on the spot, but most CPU instruction sets are similear). 10: read memory location X into register 20: add 1 to register 30: store register into memory at location X Notice there are 3 steps. Now remember that the Pentium 4 has something like 30 stages in the pipeline, I don't know exactly how they do this operation, but there could be 30 cycles between loading the memory and the store! Thats a lot of time for something else to happen. One thing that could happen is at 20: your timeslice runs out and the OS switches the other thread in, which then manipulates X (particularly changing the value of X!) before your thread gets run again where you write your X, which had 1 added to it. This is worse if your compiler is really smart, it might notice that you are manipulating g_i all over in that section of code, so the compiler loads g_i into a register, changes the value, but doesn't write it into memory right away, instead it uses the register. There are a lot of rules about when and how a compiler can do this, and most are not smart enough to make it s large problem, but unless you are locking g_i in your code the compiler has no way to know that you expect two threads to access it at the same time. I suppose there might exist an architcure where there is an atomic incriment memory operation, but if so I have never seen it. That wouldn't surprize me, I've only done assembly on 4 platforms (only one that I compiled, the rest where simplified versions of a real machine for a homework but it was never compiled)