Multithreading & Thread Safety

A piece of software is Thread-Safe if it behaves with 100% mathematical correctness during simultaneous execution by multiple concurrent threads, without data corruption, race conditions, memory visibility bugs, or deadlocks.

Thread safety bugs require the simultaneous existence of two conditions:

1. Shared State: Multiple threads can access the exact same memory address.
2. Mutable State: At least one thread modifies (writes to) that memory address.

Thread Insecurity = Shared State \land Mutable State

If state is Shared but Immutable (e.g., read-only configuration maps, frozen JSON payloads), unlimited threads can read concurrently across 128 CPU cores with zero synchronization and zero locking overhead. If state is Mutable but Thread-Local (stored exclusively on a thread's private stack or in thread-local storage), it is completely safe. Concurrency bugs occur exclusively when state is both shared and mutable.

Engineers use four hierarchical strategies to guarantee thread safety:

Strategy 1: Immutability & Pure Functions

Make objects immutable upon creation. To modify state, instantiate a new object containing the updated fields (e.g., persistent data structures in Clojure/Rust, Copy-on-Write arrays).

Strategy 2: Mutual Exclusion (Locks & Mutexes)

Wrap critical sections in mutual exclusion locks (Mutex, ReadWriteLock). Only one thread can enter the critical section at a time, serializing access to the shared resource.

Strategy 3: Hardware Atomic Operations (Lock-Free CAS)

Modern processors provide atomic instructions such as Compare-And-Swap (CAS) (e.g., LOCK CMPXCHG on x86, LDREX/STREX on ARM). CAS atomically compares the value at a memory location with an expected value, and updates it only if they match in a single indivisible hardware cycle.

Strategy 4: Shared-Nothing & Actor Models

Threads never share memory directly. Instead, threads communicate exclusively by passing immutable message payloads across channels or queues (e.g., Go channels, Erlang/Elixir actors, Rust mpsc).

"Do not communicate by sharing memory; instead, share memory by communicating." — Rob Pike

Modern superscalar CPUs and optimizing compilers aggressively reorder assembly instructions and cache writes in per-core store buffers. Without a formalized Memory Model (like the Java Memory Model or C++11 Memory Model), write operations executed on Core 0 may not become visible to Core 1 for millions of cycles, leading to bizarre memory visibility bugs.

• Instruction Reordering: Compilers reorder independent writes for optimization.
• Per-Core CPU Caches: A write to a variable sits in Core 0's store buffer/L1 cache; Core 1 reading the variable from its own L1 cache reads stale data.
• Memory Barriers (Fences): Hardware instructions (e.g., MFENCE on x86) that force the CPU to flush write buffers and synchronize cache lines across all cores.
• volatile / Atomic Load-Store: Declaring a variable volatile guarantees that every write is immediately flushed to shared memory and every read fetches the freshest value directly, establishing a formal "Happens-Before" relationship.

// Lock-Free Atomic Counter using Hardware CAS
import java.util.concurrent.atomic.AtomicLong;

public class MetricsTracker {
    private final AtomicLong requestCounter = new AtomicLong(0);

    public void recordRequest() {
        // Indivisible hardware atomic increment (No OS mutex overhead)
        requestCounter.incrementAndGet();
    }

    public long getCount() {
        return requestCounter.get(); // Guaranteed fresh read via volatile semantics
    }
}