Concurrency Basics¶

Prerequisites: OOP Fundamentals

← Design Patterns | Next: Concurrency Execution Models →

Why This Exists¶

A single-threaded ParkingLot.park_vehicle() that checks a spot is free and then marks it occupied works perfectly in every demo and fails the first time two threads (two entry gates, two API requests) call it at the same moment. Concurrency correctness is invisible in a single-threaded walkthrough and is exactly what a Senior/Staff interviewer probes for once your class design looks clean. This is step 9 from the 9-step approach — the step candidates skip because the design "already works."

Threads and Shared State¶

A thread is an independent path of execution within a process; multiple threads in the same process share memory — including the objects your LLD design created. That sharing is the entire source of concurrency bugs: two threads can read and write the same ParkingSpot instance simultaneously.

import threading

class Counter:
    def __init__(self):
        self.count = 0

    def increment(self):
        self.count += 1     # NOT atomic: read, add, write — three steps

count += 1 looks like one operation; it is read-modify-write. Two threads interleaving those three steps can both read 0, both compute 1, both write 1 — one increment is lost.

Race Conditions¶

A race condition is any outcome that depends on the unpredictable timing/interleaving of concurrent operations. The parking lot version:

sequenceDiagram
    participant T1 as Thread 1 (Gate A)
    participant T2 as Thread 2 (Gate B)
    participant S as ParkingSpot #42

    T1->>S: is_free()? → True
    T2->>S: is_free()? → True
    Note over T1,T2: both saw "free" — the race window
    T1->>S: occupy(car_1)
    T2->>S: occupy(car_2)
    Note over S: car_2 silently overwrote car_1.<br/>Two cars now believe they own spot #42.

Check-then-act (is_free() then occupy()) is not atomic unless you make it so. The fix is collapsing the check and the act into one operation the runtime guarantees is indivisible:

import threading

class ParkingSpot:
    def __init__(self, spot_id: str):
        self.spot_id = spot_id
        self._occupied_by = None
        self._lock = threading.Lock()

    def try_occupy(self, vehicle) -> bool:
        with self._lock:                    # check AND act inside one critical section
            if self._occupied_by is not None:
                return False
            self._occupied_by = vehicle
            return True

The method name change (try_occupy returning bool instead of separate is_free() + occupy()) is itself part of the fix — it makes atomicity part of the interface contract, not an accident of how callers happen to use it.

Locks¶

A lock (mutex) ensures only one thread executes a critical section at a time; other threads block until it's released.

class ParkingLot:
    def __init__(self, spots: list[ParkingSpot]):
        self._spots = spots
        self._lock = threading.Lock()

    def park_vehicle(self, vehicle) -> "Ticket | None":
        with self._lock:                          # coarse: whole lot locked per park() call
            for spot in self._spots:
                if spot.size == vehicle.spot_size_required() and spot.try_occupy(vehicle):
                    return Ticket(spot, vehicle)
            return None

Deadlocks¶

A deadlock is two or more threads each holding a lock the other needs, so neither can proceed — permanently, not just slowly.

flowchart LR
    T1["Thread 1<br/>holds Lock A<br/>wants Lock B"] -.waits for.-> T2
    T2["Thread 2<br/>holds Lock B<br/>wants Lock A"] -.waits for.-> T1
    style T1 fill:#b71c1c,color:#fff
    style T2 fill:#b71c1c,color:#fff

The classic setup: a transfer(from_account, to_account) method that locks from_account then to_account. Two threads calling transfer(A, B) and transfer(B, A) simultaneously can each grab their first lock and then block forever waiting for the second.

# Deadlock-prone: lock order depends on call argument order
def transfer(from_acct, to_acct, amount):
    with from_acct.lock:
        with to_acct.lock:
            from_acct.balance -= amount
            to_acct.balance += amount

The fix: a consistent global lock ordering, independent of call argument order — e.g. always lock the account with the lower account ID first:

def transfer(from_acct, to_acct, amount):
    first, second = sorted([from_acct, to_acct], key=lambda a: a.account_id)
    with first.lock:
        with second.lock:
            from_acct.balance -= amount
            to_acct.balance += amount

Every thread now acquires locks in the same relative order, so the circular-wait condition that causes deadlock can't form.

The four conditions all required for deadlock (removing any one prevents it): mutual exclusion, hold-and-wait, no preemption, circular wait. Consistent lock ordering removes circular wait — usually the cheapest one to remove in an interview answer.

Thread Safety Without Locks¶

Locks aren't the only tool — sometimes the cheaper fix is removing the shared mutable state entirely:

• Immutability — an object that can't change after construction can't have a race on its fields. A Ticket created once with entry_time, spot_id, vehicle_id set in the constructor and never mutated is safe to read from any thread with no lock.
• Thread-confinement — give each thread its own copy of the state instead of sharing one instance (e.g., a per-request object instead of a shared singleton).
• Atomic types / compare-and-swap — some languages provide atomic primitives (AtomicInteger, compareAndSet) that give you the check-and-act guarantee without an explicit lock, cheaper than a mutex for simple counters.
• Concurrent collections — a thread-safe queue or map (rather than a plain list/dict guarded by a lock you have to remember to take every time) removes an entire class of "forgot to lock this access site" bugs.

Trade-offs¶

Interview Questions¶

Key Takeaways¶

Previous: Design Patterns | Next: Concurrency Execution Models