Explain atomic operations, memory visibility, and memory barriers.

Question

IT Interview Practice · Accepted Answer

**An atomic operation completes indivisibly — no other thread sees a half-done state; memory visibility is whether one thread's writes are seen by another; memory barriers enforce ordering so those writes become visible.** Locks are not the only concern — the memory model is.

## Atomicity

An atomic op (e.g. `fetch_add`, compare-and-swap) executes as one indivisible step, so no race splits it. Hardware and language provide atomics for counters and flags without a full lock.

```java
AtomicInteger counter = new AtomicInteger();
counter.incrementAndGet();  // atomic read-modify-write, no lock
```

## Visibility and reordering

Modern CPUs and compilers cache values in registers and reorder instructions for speed. So a write in one thread may sit in a store buffer, invisible to others, and operations may appear out of order.

```java
// Without 'volatile', thread B may loop forever:
volatile boolean ready = false;  // volatile → writes are visible + ordered
// Thread A: data = 42; ready = true;
// Thread B: while (!ready) {}  then read data
```

## Memory barriers

A **barrier** (fence) is a instruction that prevents reordering across it and flushes/loads memory, guaranteeing ordering. `volatile`, `synchronized`, and atomics insert the right barriers so a happens-before relationship holds: what A wrote before releasing, B sees after acquiring.

## Why it matters

Atomicity alone isn't enough — without visibility guarantees a correctly-locked value can still be read stale. This explains why `volatile` exists, why double-checked locking is subtle, and why lock-free code needs careful memory-ordering choices. It's the difference between "works on my machine" and correct on real multi-core hardware.

Atomicity

Visibility and reordering

Memory barriers

Why it matters

Related questions