Atomics & CAS: interview questions & scenarios

Model answer

Picture a shared Google Doc with a rule: "you may change the number in cell A1 only if it still says what you last saw." You read 41, work out 42, and go to save. If A1 still says 41, your 42 goes in. If someone changed it to 50 while you were thinking, your save is rejected and you try again with fresh eyes.

That's compare-and-swap: one indivisible step that says "if the value is still expected, set it to new, and tell me whether it worked."

AtomicInteger stock = new AtomicInteger(41);
boolean ok = stock.compareAndSet(41, 42);   // true: it was 41, now 42
boolean no = stock.compareAndSet(41, 43);   // false: it's 42 now, nothing changed

Three things make it special:

• It's one hardware instruction, not a lock. On x86 it's LOCK CMPXCHG; on ARM64 it's CAS (with LSE atomics) or an LDXR/STXR retry pair. No thread is ever put to sleep.
• It's optimistic. You assume nobody will interfere, do your work, and check at the end. A lock is pessimistic: it stops everyone else up front.
• Failure is cheap and visible. A failed CAS changes nothing and returns false, so you can loop and retry.

In Java, compareAndSet on an atomic class also has volatile memory semantics: a successful CAS acts like a volatile read plus a volatile write, so whatever you wrote before it is visible to the next thread that reads the variable.

Model answer

volatile fixes seeing. AtomicInteger fixes seeing and changing in one step.

count++ on a volatile int is still three separate steps: read, add one, write. volatile guarantees each read sees the latest write and each write is published, but two threads can both read 41, both compute 42 and both write 42. One increment vanishes. That's a lost update, and volatile does nothing about it.

volatile int hits;                     // visible, but hits++ still loses updates
final AtomicInteger safeHits = new AtomicInteger();
safeHits.incrementAndGet();            // read, add and write as one atomic step

So AtomicInteger is "a volatile int plus atomic read-modify-write operations": incrementAndGet, getAndAdd, compareAndSet, updateAndGet, accumulateAndGet. Its get() and set() behave like a volatile read and a volatile write.

volatile alone is perfect for a single writer, many readers flag, like volatile boolean running. As soon as more than one thread does read-modify-write, you need an atomic or a lock. The volatile lesson walks through this with a real stop-flag demo.