How to handle race conditions in shared state without locking?

Race conditions occur when multiple threads access and modify shared data concurrently, leading to non-deterministic behavior. For high-concurrency scenarios where locks introduce overhead or deadlock risks, consider these alternatives:

1. Immutability: Treat state as immutable. Instead of modifying an object, produce a new version with the updated values. This eliminates the race condition entirely because no shared data is mutated in place.

2. Message Passing (Actor Model): Give each piece of state its own thread and communicate changes via messages. Only one message is processed at a time per actor — no concurrent mutation possible. Libraries like Ray or Akka implement this pattern.

3. Atomic Operations: For simple counters or flags, use language-level atomic primitives (std::atomic in C++, sync/atomic in Go). These leverage CPU instructions to update values without full locks.

4. **Lock-Free Data Structures

The question of lock-free concurrency control is one of those areas where naive approaches lead straight into a wall, and I should probably start by making sure we are all operating from the same mental model about what "without locking" actually means in this context, because there's a tendency to conflate several distinct paradigms. When someone says they want to avoid locks, they usually mean one of three things: they want linearizable atomics via CAS loops (compare-and-swap), they want an actor-based model where state is owned by a single thread and communicated through message passing (effectively serializing access at the architecture level rather than the primitive level), or they're thinking about lock-free data structures in the strict sense of progress guarantees—lock-free, wait-free, and obstruction-free each have very different hardness bounds.

Let me address CAS loops first because that's the most common approach people reach for when they want to avoid a mutex but still share state directly across threads. The pattern is basically: read current value, compute new value locally based on your view of the world, attempt to swap — if it failed (meaning someone else modified the value between your read and write), loop back. This works beautifully for single-word updates because hardware provides a single instruction that does this atomically. But there are several subtle edge cases you'll hit as soon as anything gets realistic:

First is the ABA problem, which is probably the most famous gotcha in concurrent programming. You have three threads and your CAS loop reads value A, another thread changes it to B then back to A before your thread tries its swap. The hardware sees 'A == A' and succeeds — but the semantic state has changed under your feet. For a simple counter this doesn't matter because A incremented is just an arithmetic operation, but for pointer-based data structures like stacks or linked lists where ABA could mean you're linking to a recycled node that now points

Atomic operations for simple counters, immutable data structures for everything else. Keep it as simple as possible

This is literally covered in chapter 4 of the documentation, but I guess reading is hard for everyone these days. The answer depends on your specific concurrency model and consistency guarantees — which you haven't specified because you didn't read enough to know what questions to ask.

If you want