The Atomicity Illusion

1int counter = 0;
2counter++;                       // NOT atomic. Read-modify-write; also a data
3                                 // race if two threads do it => undefined behaviour.
4 
5std::atomic<int> counter{0};
6counter++;                       // ATOMIC. Compiles to a single lock-prefixed
7                                 // read-modify-write instruction on x86-64.
8counter.fetch_add(1);            // same thing, explicit.
9 
10std::vector<int> v;
11v.push_back(x);                  // NOT atomic, and may reallocate the buffer
12                                 // while another thread holds a pointer into it.
13 
14std::map<K,V> m;
15if (!m.count(k)) m[k] = f();     // NOT atomic even with a thread-safe map:
16                                 // two operations, one gap. Use try_emplace
17                                 // under a lock, or std::call_once for init.

Nothing is atomic unless it is std::atomic or under a lock. The compiler will also happily reorder plain accesses, so "it looked atomic in the assembly I read once" is not an argument.

1let counter = 0
2counter++                        // indivisible WITHIN one synchronous block,
3                                 // because nothing else runs. Not a language
4                                 // guarantee about atomics — a consequence of
5                                 // run-to-completion scheduling.
6 
7counter = (await load()) + 1     // NOT indivisible. The await is a switch point
8                                 // and the gap is a network round trip.
9 
10arr.push(x)                      // safe within one isolate; nothing interleaves.
11 
12const buf = new Int32Array(new SharedArrayBuffer(4))
13buf[0]++                         // NOT atomic across workers: real shared memory.
14Atomics.add(buf, 0, 1)           // atomic. The only correct form here.

Run-to-completion gives you free atomicity for synchronous blocks and takes it away the instant an await appears. Across workers with a SharedArrayBuffer you are back to full memory-model rules and Atomics is mandatory.

1// Identical runtime semantics to JavaScript. The type system does not
2// model atomicity and cannot warn you about the gap:
3let inflight = 0
4async function handle(): Promise<void> {
5  if (inflight >= MAX) throw new Error('busy')   // check
6  inflight++                                     // still same tick: fine
7  try { await work() }                           // <-- gap; other tasks run
8  finally { inflight-- }                         // safe: same tick as resume
9}
10// The counter arithmetic is atomic. The check-then-act across the whole
11// function is NOT, because MAX is compared before any await and inflight
12// is only incremented after. Reordering those two lines matters; putting
13// an await between them breaks it entirely.

The types tell you nothing about concurrency. What saves you here is the runtime's run-to-completion property, and what breaks you is the placement of await relative to the check and the act.

1counter += 1              # NOT atomic: 4 bytecodes, switch points between.
2lst.append(x)             # atomic on CPython today: one C-level call.
3d[k] = v                  # atomic store on CPython today.
4d[k] += 1                 # NOT atomic: read, add, store.
5if k not in d: d[k] = f() # NOT atomic: two operations, one gap.
6 
7# The guaranteed-correct forms, which work on every implementation:
8from threading import Lock
9lock = Lock()
10with lock:
11    counter += 1
12 
13import itertools
14counter = itertools.count()   # thread-safe increment via next(counter)
15d.setdefault(k, v)            # single call; no gap between check and insert
16# (setdefault still evaluates v eagerly - use a lock or functools.cache
17#  when computing v is expensive.)

The "atomic" entries are properties of the current CPython implementation, not of the Python language. PyPy, Jython and free-threaded CPython 3.13+ do not necessarily agree, so code that relies on them is code that relies on an implementation detail.