title: Can num++ be atomic for 'int num'?
body: <p>In general, for <code>int num</code>, <code>num++</code> (or <code>++num</code>), as a read-modify-write operation, is <strong>not atomic</strong>. But I often see compilers, for example <a href="https://en.wikipedia.org/wiki/GNU_Compiler_Collection" rel="noreferrer">GCC</a>, generate the following code for it (<a href="https://godbolt.org/g/UFKEvp" rel="noreferrer">try here</a>):</p>
  <pre class="lang-c prettyprint-override"><code>void f()
  {
    int num = 0;
    num++;
  }
  </code></pre>
  <pre><code>f():
          push    rbp
          mov     rbp, rsp
          mov     DWORD PTR [rbp-4], 0
          add     DWORD PTR [rbp-4], 1
          nop
          pop     rbp
          ret
  </code></pre>
  <p>Since line 5, which corresponds to <code>num++</code> is one instruction, can we conclude that <code>num++</code> <strong>is atomic</strong> in this case?</p>
  <p>And if so, <strong>does it mean that so-generated <code>num++</code> can be used in concurrent (multi-threaded) scenarios without any danger of data races</strong> (i.e. we don't need to make it, for example, <code>std::atomic&lt;int&gt;</code> and impose the associated costs, since it's atomic anyway)?</p>
  <p><strong>UPDATE</strong></p>
  <p>Notice that this question is <em>not</em> whether increment <em>is</em> atomic (it's not and that was and is the opening line of the question). It's whether it <em>can</em> be in particular scenarios, i.e. whether one-instruction nature can in certain cases be exploited to avoid the overhead of the <code>lock</code> prefix. And, as the accepted answer mentions in the section about uniprocessor machines, as well as <a href="https://stackoverflow.com/a/39414316/4973224">this answer</a>, the conversation in its comments and others explain, <strong>it can</strong> (although not with C or C++).</p>