Is assignment to int atomic
-
Hi, i work in c++ using Visual Studio 2005. I'd like to know if the assignment operation to int (like int i; i=5; ) is atomic. If yes, can you show me proof for that? It is the same in x64 OS?
-
Hi, i work in c++ using Visual Studio 2005. I'd like to know if the assignment operation to int (like int i; i=5; ) is atomic. If yes, can you show me proof for that? It is the same in x64 OS?
it can be, but i doesn't have to. if you want to be sure use the volatile keyword. [code] volatile int test; int main(int argc, const char *argv[]) { test = 5; // this is atomic! } [/code]
Don't try it, just do it! ;-)
-
it can be, but i doesn't have to. if you want to be sure use the volatile keyword. [code] volatile int test; int main(int argc, const char *argv[]) { test = 5; // this is atomic! } [/code]
Don't try it, just do it! ;-)
Why the
volatilekeyword make it atomic?If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Hi, i work in c++ using Visual Studio 2005. I'd like to know if the assignment operation to int (like int i; i=5; ) is atomic. If yes, can you show me proof for that? It is the same in x64 OS?
Dudi Avramov wrote:
I'd like to know if the assignment operation to int (like int i; i=5; ) is atomic.
No, absolutely not. There is much more to atomic operations. 1.)The LOCK[^] prefix must be present to instruct the processor that it has exclusive memory access to the variable location. 2.) Modern processors perform speculative fetching and instruction reordering so the code being executed should be serialized before the atomic operaration with SFENCE[^]/LFENCE[^]/MFENCE[^] The volatile keyword[^] should give the compiler a hint that it needs to prevent out-of-order execution which may result in a Memory Barrier[^]. Interlocked Variable Access[^] Synchronization and Multiprocessor Issues[^] Best Wishes, -David Delaune
-
it can be, but i doesn't have to. if you want to be sure use the volatile keyword. [code] volatile int test; int main(int argc, const char *argv[]) { test = 5; // this is atomic! } [/code]
Don't try it, just do it! ;-)
Not true. All volatile does is to tell the compiler to write the value back to memory when it's changed AND that something else may change the variable. Without volatile, under some circumstance it could optimize it a register and only write and/or fetch it periodically.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Why the
volatilekeyword make it atomic?If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Definitely not.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Dudi Avramov wrote:
I'd like to know if the assignment operation to int (like int i; i=5; ) is atomic.
No, absolutely not. There is much more to atomic operations. 1.)The LOCK[^] prefix must be present to instruct the processor that it has exclusive memory access to the variable location. 2.) Modern processors perform speculative fetching and instruction reordering so the code being executed should be serialized before the atomic operaration with SFENCE[^]/LFENCE[^]/MFENCE[^] The volatile keyword[^] should give the compiler a hint that it needs to prevent out-of-order execution which may result in a Memory Barrier[^]. Interlocked Variable Access[^] Synchronization and Multiprocessor Issues[^] Best Wishes, -David Delaune
Is it possible that the mov assembly instruction is not atomic?
-
Is it possible that the mov assembly instruction is not atomic?
It is possible that it's not atomic - if the processor doesn't have the bus locked while performing the MOV, some other bus attached hardware (like, for example, the other core of the processor, or some hardware performing a DMA) could theoretically write to that memory location if it has precedence over the current processor.