2

Can I assume that each instruction is observed atomicity? for example,

mov dword ptr [eax], 0

The movement either move successfully or doesn't happen. there is no interrupt in the middle of the instruction executed.

Is my assumption right?

I know the current processor can execute instruction out of order, and compiles will generate codes out of order in terms of optimization. And hence the movement will be executed in the order which isn't same as I wrote. But this doesn't matter, what i concern is once the single instruction is executed, it can't be interrupted.

EDIT:
what I concern is atomicity of any single instruction, not an special instruction or a branch of read-write instructions, I just use mov for example.

  1. Any time when any core of processor executes an instruction(add,mov,shift, etc.), can the execution be interrupted?
  2. Is there any indeterminate state in the register or the memory(machine-word-size).

Or what is the smallest unit that hardware can provide atomicity?

Chang
  • 3,953
  • 2
  • 30
  • 43
  • http://stackoverflow.com/questions/1762148/atomic-instruction – Mitch Wheat Apr 11 '11 at 01:57
  • Your question makes no sense; if `K` is a constant (immediate), then no memory is involved, except the actual program text. (I hope you're not trying to reason about the behavior of self-modifying code in the presence of SMP/threads...) So there is no way other threads could even see or be affected by these instructions... – R.. GitHub STOP HELPING ICE Apr 11 '11 at 01:58
  • "each instruction is observed atomicity" -> not english. you could say "is observed atomically" or "is observing atomicity". and they are different. – v.oddou Mar 20 '14 at 01:23

2 Answers2

4

NO. You generally should not assume that instructions are atomic. With regard to loading a register with a constant why would that matter anyways? Are you asking if the register can end up in an indeterminate state? The answer to that is no, otherwise interrupts wouldn't work. The register would either be loaded or not loaded from the view point of a program running on the same core.

The LOCK prefix in x86 is there to ensure atomicity.

EDIT: Question has been edited to show storing a constant into memory. And my answer is still generally no. There may be some situations where if the memory is aligned, and the CPU makes that guarantee this will be atomic but I wouldn't rely on it as it could get you into trouble.

Also see here: Read/Write an int on x86 machine without lock

Community
  • 1
  • 1
Guy Sirton
  • 8,331
  • 2
  • 26
  • 36
  • I updated question again. so are you mean the single instruction will be interrupted? actually i am asking if the aligned memory can end up with an indeterminate state. – Chang Apr 11 '11 at 05:07
  • On **x86**, plain loads and stores (`MOV` instructions) are atomic when applied to aligned memory operands in "normal" memory. For anything else other than `XCHG` and instructions with the `LOCK` prefix, it is best to assume it is **NOT** atomic. Even plain loads and stores are not necessarily atomic on non-x86 platforms. See my article on the non-atomicity of `INC`: http://www.devx.com/cplus/Article/42725 – Anthony Williams Apr 11 '11 at 09:45
0

You've tagged this question C and C++, but neither language has a mov instruction or any notion of individual instructions. If your question is really about x86 assembly, then yes mov instructions are atomic, at least as long as the memory operand is aligned, and probably even if it's not. Note however that this has nothing to do with whether assignment to C or C++ variables is atomic.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 1
    Well, a MOV instruction that stores a value across a cache line boundary isn't atomic. Neither are string moves (MOVS), which are *designed* to be interruptable/restartabled. So in general, MOV instructions are not atomic (let alone more complex ones). There are special cases in which MOV instructions *are* atomic: specifically, the operand loaded/stored is accessed on a boundary equal in size to the operand, for items that are word-sized and above. Otherisw you'd better use synchronization instructions. XCHG oddly *is* atomic because Intel made that way back in early CPUs. – Ira Baxter Apr 11 '11 at 02:20
  • @Ira: I already limited my answer to "at least as long as the memory operand is aligned" which precludes crossing cache line boundaries. – R.. GitHub STOP HELPING ICE Apr 11 '11 at 02:57
  • @Ira Baxter speak of cache line, I am a litter confused, how do you across a machine-word-size integer cache line boundary? – Chang Apr 11 '11 at 03:00
  • @Chang: Store the word at an address corresponding to the last byte of the cache line. – Ira Baxter Apr 11 '11 at 03:20
  • @Ira Baxter, I can conclude aligned address will not be affected by cache line, and hence it is atomic, as R.. wrote above, can I? – Chang Apr 11 '11 at 04:34
  • @Chang: operand-aligned addresses don't cross cache line boundaries, correct. They are atomic only for word-size operands an up, IIRC; I don't think byte updates are atomic. If you want to know the ugly details, you really need to read the Intel architecture manual. There's one online at the Intel site. – Ira Baxter Apr 11 '11 at 04:42
  • On any sane architecture, byte updates are atomic. Certainly on any x86. I'm 99% sure halfword (16-bit) updates are too, as long as they don't cross cache line boundaries. – R.. GitHub STOP HELPING ICE Apr 11 '11 at 04:50