Overview

No -- asyncio on one OS thread is concurrency (dealing with many things by interleaving), not parallelism (doing many things at once on multiple cores). A single thread can only ever run one instruction at a time, no matter how many coroutines it juggles; true parallelism requires more than one thread or process actually executing simultaneously (Example 1 illustrates the two side by side; Example 81 contrasts a thread-pool/asyncio fetch against a genuinely parallel process-pool aggregate).

Threads share ONE process's address space, so spawning a thread is cheap (no memory copy, no separate interpreter) but also dangerous: any thread can directly read or write another thread's data with zero isolation, which is exactly what makes unsynchronized shared mutation possible. Processes have isolated address spaces -- safer by construction, since one process's corruption or crash cannot directly touch another's memory -- but every spawn and every cross-process communication costs real copying/IPC overhead (Example 2 contrasts the two directly; Examples 45-46 show a global mutated in a child process being invisible to the parent, precisely because of that isolation).

CPython's Global Interpreter Lock allows only ONE thread to execute Python bytecode at any instant, regardless of how many CPU cores are available -- CPU-bound threaded work serializes onto effectively one core, so wall time approaches (or, with switching overhead, slightly exceeds) the single-threaded time (Example 3 demonstrates the serialization directly; Examples 25, 49, 58, and 77 each measure this same ceiling from a different angle).

A free-threaded (python3.14t) build removes the GIL entirely, so CPU-bound threads can genuinely execute Python bytecode simultaneously across multiple cores -- officially supported since Python 3.14 per PEP 779, though it remains an opt-in build variant, and platform installers (macOS's, notably) may still label the option "experimental" in their own UI even though the PEP itself calls it supported (Example 4 detects which build is running; Examples 58-59 measure real CPU-bound speedup on it).

The fetch step is I/O-bound -- it spends nearly all its time WAITING (on the network), and a waiting thread releases the GIL, so threads or asyncio overlap the waits efficiently. The compression step is CPU-bound -- it spends its time actually COMPUTING, so only separate processes (each with its own interpreter and its own GIL) genuinely parallelize it; threads would just serialize on the GIL the same way Q3 describes (Examples 3, 5, 23, 28, 48, 49, 59, 76, and 77 each classify a workload this way before choosing a tool).

start() schedules the thread's target function to begin running CONCURRENTLY and returns immediately -- it does not wait for the target to finish. join() blocks the CALLING thread until the target thread's function has actually returned. Forgetting join() means the caller can proceed (or the whole program can exit) before spawned threads finish their work (Examples 5-7 build up from one thread to several, each explicitly joined).

Nearly every failure mode this topic covers -- races, deadlocks, visibility surprises -- only exists BECAUSE some piece of mutable state is reachable and writable from more than one thread at the same time. If no state were ever shared and mutable simultaneously, none of locks, semaphores, or conditions would be necessary at all -- they all exist specifically to manage this one hazard (Example 8's shared counter; Example 64's threading.local() fix removes the hazard by giving each thread its OWN, unshared copy).

A race condition is a bug where the OUTCOME of a program depends on the particular, nondeterministic order in which concurrent operations happen to interleave -- the exact same code, run with the exact same inputs, can produce different results on different runs, because the operating system's scheduler decides the interleaving, not the program (Examples 8, 10, 11, and 37 reproduce one directly; Example 60 shows a subtler one inside lazy singleton construction; Example 80's stress harness exists because a single passing run proves nothing about race-freedom).

No. A data race is the narrower, mechanically-checkable case: unsynchronized concurrent access to the SAME memory location where at least one access is a write. A race condition is the broader, semantic category -- any bug where output depends on interleaving timing, which can happen even WITHOUT a data race, e.g. two properly-locked operations still running in an unintended overall order for the business logic they implement (Example 37 deliberately shows the two failing in DIFFERENT observable ways).

x += 1 is really three separate steps -- read the current value of x, compute x + 1, write the result back -- and CPython performs no magic to make those three steps indivisible as a group. Another thread can interleave between any of them, so its own read can see a stale value and its own write can silently be overwritten, losing an update (Example 9 proves this via dis bytecode inspection; Example 36 generalizes the point to ANY read-modify-write, not just +=).

A Lock guarantees mutual exclusion: at most ONE thread can be executing inside that block at any given instant. Any other thread attempting to acquire the same lock BLOCKS until the current holder releases it, which eliminates interleaving inside that specific critical section entirely (Examples 11-12 fix a racing counter with one; Examples 14, 31, 36, 47, 60, 61, and 80 each apply the same guarantee to a different scenario).

A plain Lock tracks only "held or not held," never WHO holds it -- so a second acquire() call from the SAME thread that already holds it blocks waiting for a release() that same thread would have to perform first, which can never happen because that thread is itself blocked. An RLock tracks the owning thread plus a re-entry count, letting that SAME thread re-acquire it without blocking, as long as it eventually calls release() once per acquire() (Example 13 shows the RLock working; Example 14 shows the plain Lock deadlocking on the identical re-acquire attempt).

A Lock permits exactly one holder at a time. A Semaphore(N) permits up to N CONCURRENT holders -- acquire() decrements an internal counter (blocking once it reaches zero) and release() increments it back, letting up to N callers hold the semaphore simultaneously instead of just one, useful for capping concurrent access to a resource pool sized N (Examples 15-16 build and then stress-test the bound; Examples 53, 61, and 69 apply it to a rate-limited or reader-writer scenario).

A Condition pairs a lock WITH a wait/notify mechanism: a thread inside with cond: can call cond.wait() to atomically release the lock and block, until another thread changes some shared state and calls cond.notify()/notify_all(), at which point the waiter automatically re-acquires the lock before proceeding. This solves "block until a specific condition becomes true" without a wasteful busy-loop that burns CPU checking a flag repeatedly (Example 19's basic wait/notify; Example 41's hand-built bounded buffer; Example 74's while guard against a spurious/early wakeup).

An Event is a one-shot broadcast signal -- any number of waiters unblock once set() is called, and it stays set (any FUTURE waiter also passes through immediately) until explicitly clear()ed. A Barrier is a rendezvous point for a FIXED number of parties -- every participant blocks at wait() until exactly N have arrived, then all N are released together at once, and the barrier automatically resets for reuse on the next round (Example 17's one-shot Event signal; Example 18's rendezvous; Example 75's Barrier synchronizing phased parallel computation across multiple rounds).

Mutual exclusion (a resource can only be held by one thread at a time), hold-and-wait (a thread holds one resource while waiting for another), no preemption (a resource cannot be forcibly taken away from its holder), and circular wait (a cycle of threads, each waiting on a resource the next one in the cycle holds). All four must hold simultaneously for a deadlock to occur; lock-ordering discipline specifically removes circular wait, the only one of the four that's usually practical to eliminate outright (Examples 29, 31, and 34 reproduce and analyze a real deadlock; Examples 62 and 79 apply the same diagnosis to a wait-for graph and dining philosophers).

In deadlock, every involved thread is BLOCKED and makes zero progress. In livelock, threads stay ACTIVE (never blocked) but keep changing state in RESPONSE to each other without either one ever making real progress -- like two people repeatedly stepping the same direction to avoid colliding in a hallway. Starvation is different again: one SPECIFIC thread is perpetually denied the resource it needs while OTHER threads make progress just fine, no mutual back-and-forth required (Example 32 reproduces livelock; Example 33 reproduces a producer starved by greedy consumers).

If every thread that needs multiple locks always acquires them in the SAME globally-agreed order, a cycle (thread A waiting for a lock thread B holds, while B waits for a lock A holds) can never form -- whichever thread reaches the shared FIRST lock in that order simply proceeds and eventually releases both. This doesn't remove mutual exclusion (locks still exclude), hold-and-wait (a thread can still hold one while waiting for the next), or no-preemption (locks still can't be forcibly taken) -- it specifically makes the circular-wait SHAPE impossible to construct in the first place (Example 30 fixes Example 29's deadlock this exact way; Examples 62 and 79 apply the same fix elsewhere).

Without synchronization, there is no language-level GUARANTEE about when (or, in a stricter memory model, whether) one thread's write becomes visible to another thread's read -- a read could observe a stale cached view. In practice, CPython's GIL makes many such cases "just happen to work" as a side effect of byte-code-granularity switching, which is exactly why relying on it is fragile: it's an implementation coincidence, not a portable guarantee any other Python implementation (or a future free-threaded build) is obligated to preserve (Example 35's busy-wait flag "works" yet is flagged as fragile for this reason; Examples 64 and 72 explore adjacent visibility/isolation boundaries).

Instead of multiple threads reading and writing the SAME mutable variable (needing a lock around every single access to stay safe), each thread privately owns its own state and hands DATA to others through a thread-safe channel -- there is no shared mutable location left to race on at all, because ownership of each piece of data transfers explicitly through the channel rather than being simultaneously accessible to everyone (Example 20's put()/get() handoff; Examples 46 and 63 apply the same idea across a process boundary and via a single-owner queue standing in for a lock-free counter).

queue.Queue wraps its own internal deque with its own Lock/Condition machinery -- every put() and get() call is ALREADY synchronized inside the queue's own implementation, so callers never need to wrap queue operations in their own extra lock; the queue itself is the synchronization boundary (Example 20's basic hand-off; Examples 38 and 40 exercise backpressure and task_done()/join(); Examples 63 and 70 build a lock-free counter and a multi-stage pipeline on top of this same guarantee).

An unbounded buffer lets a fast producer pile up an unlimited number of unconsumed items in memory if consumers can't keep pace, risking unbounded memory growth. A bounded buffer applies BACKPRESSURE: put() blocks once the buffer reaches its maximum size, forcing the producer to slow down to match the consumer's actual processing rate, rather than racing ahead indefinitely (Example 38 applies backpressure to a fast producer directly; Examples 21-22, 39-41, 52, 70, and 78 build progressively richer producer/consumer pipelines on the same bounded-buffer idea).

Manually creating a fresh Thread object for every unit of work, individually tracking each one to join() it, and managing an unbounded, potentially huge number of concurrently-live threads. A pool creates a FIXED number of long-lived worker threads up front and hands them a shared queue of work, bounding concurrency AND reusing threads across many tasks instead of paying creation/teardown cost per task (Examples 23-24 submit work and collect a Future; Examples 42-43, 48, 55, 65, 73, 76, 78, and 81 apply pools to progressively more realistic scenarios).

Whenever the work is genuinely CPU-bound -- threads in a ThreadPoolExecutor still serialize on the GIL for CPU-heavy work (Q3), so a ProcessPoolExecutor, where each worker is a fully separate interpreter with its OWN GIL, is the tool that actually uses multiple cores in parallel (Example 25 beats threads on CPU work directly; Examples 44, 47, 57, 72, 77, and 81 each apply process pools to a CPU-bound or IPC-heavy workload).

A Future is a placeholder object standing in for a result that may not exist YET -- calling .result() on it blocks until the underlying work actually completes (or re-raises whatever exception that work raised), while the Future object itself can be inspected, have a callback attached with add_done_callback, or be cancelled (only while genuinely still pending) without ever blocking (Example 24 submits and blocks on .result(); Example 26 attaches a completion callback; Examples 42-43 and 65 explore completion ordering, exception propagation, and cancellation).

A coroutine object by itself does nothing until something drives it. The asyncio EVENT LOOP repeatedly resumes each scheduled coroutine from exactly where it last awaited, running everything on a SINGLE OS thread by cooperatively switching between coroutines at each await point -- nothing runs "in the background" independent of the loop actively servicing it (Example 27's first coroutine; Example 28's gather; Examples 50-54, 66-69, 76, and 81 build up realistic concurrent-coroutine scenarios).

await is a voluntary, explicit yield point that the coroutine's OWN code chooses -- control only passes back to the event loop exactly there, nowhere else. OS thread preemption is involuntary: the scheduler can interrupt a running thread at essentially any instruction boundary to give another thread a turn, which is precisely why threaded code needs locks even around operations that "look" instantaneous, while a single coroutine's code between two await points is guaranteed to run without another coroutine interleaving into it (Example 54's blocking-call hazard shows what breaks when a coroutine forgets to actually yield; Examples 55, 67, and 73 apply the cooperative model correctly).

No -- Amdahl's Law caps the maximum possible speedup at 1 / (serial fraction), so with a 20% serial portion, the theoretical CEILING is 1 / 0.2 = 5x, no matter how many cores are thrown at the remaining 80%. The parallel portion can, in principle, be sped up arbitrarily as workers increase; the serial portion is always paid in full, on every run, regardless of core count (Example 56 computes the ceiling directly; Example 57's map-reduce decomposition and Example 75's phased barrier both respect this same ceiling in practice).

A plain push API gives a slow subscriber no way to tell a fast publisher "slow down" -- values just arrive as fast as the publisher produces them. The Reactive Streams spec adds Subscription.request(n) specifically so a subscriber can bound how much a publisher is allowed to push at once, making non-blocking backpressure a first-class, contractually-enforced part of the API rather than something bolted on afterward with an ad-hoc buffer (Example 85 exercises reactive pull directly; Example 86 hand-rolls the same four-interface contract the JDK adopted as java.util.concurrent.Flow).

An Iterable is PULLED -- its consumer actively calls next() to ask for the next value, on the consumer's own schedule. An Observable is PUSHED -- its producer calls onNext/onError/onCompleted on its subscriber whenever it has something, on the PRODUCER's own schedule, without ever being asked. Chaining map/filter builds a NEW Observable that wraps the source, transforming or filtering each pushed value before re-pushing it downstream, composing an entire transformation pipeline declaratively (Example 82 builds and subscribes to exactly this kind of pipeline; Example 87's marble diagram visualizes several chained operators over time).

A COLD Observable only starts producing values once something subscribes to it, so a late subscriber still gets the WHOLE sequence, replayed from the start on its own independent timeline. A HOT Observable (backed by a Subject) emits on its own schedule regardless of whether anyone is subscribed, so a late subscriber simply MISSES whatever already happened before it subscribed -- there is no replay (Example 83 runs both scenarios side by side against the identical sequence, so the difference is directly observable).

Buffer (or drop, or keep-latest, or error) are all REACTIVE fixes applied AFTER the mismatch already exists -- the stream decides what to do with excess items once they've already been produced faster than they're consumed. Reactive pull inverts the relationship at its root: the SUBSCRIBER states its own current demand up front via request(n), and the producer is contractually bound to emit no more than that amount -- the mismatch is prevented at the source rather than patched after the fact (Example 84 hand-rolls buffer-all vs. keep-latest, since RxPY 4.1.0 ships no built-in backpressure operators; Example 85 shows the pull-based alternative).

No. The Reactive Manifesto (responsive / resilient / elastic / message-driven) is an ARCHITECTURAL set of system-design goals, not a programming model by itself, and Rx-style reactive streams model DISCRETE events over time (a series of onNext calls). Original FRP (Elliott & Hudak, 1997) is a distinct, older idea built on CONTINUOUS-time behaviors (values that conceptually exist at every instant) plus discrete events -- genuinely different semantics that happen to share the word "reactive" (Example 87's marble diagram is explicitly discrete-event, in the Rx sense, not continuous-time FRP).

Image resizing is CPU-bound work, and CPython's GIL (co-03) serializes Python bytecode execution across threads regardless of thread count or core count -- 8 threads doing CPU-bound work still run one at a time, with some added context-switch overhead, explaining the near-1x result. Because the workload is CPU-bound rather than I/O-bound (co-05), the fix is ProcessPoolExecutor (co-24) instead of ThreadPoolExecutor -- separate processes each get their own interpreter and their own GIL, genuinely using multiple cores.

inventory["widget"] -= 1 is a read-modify-write, not one atomic step (co-10) -- two threads can both read the SAME pre-decrement value, both compute "one less," and both write back the same result, silently losing one decrement (co-08, a classic race condition). The minimal fix is wrapping the decrement in a threading.Lock (co-11) so the whole read-modify-write happens as one uninterruptible step.

This is a deadlock (co-16): billing holds customer_record while waiting for warehouse_record, and shipping holds warehouse_record while waiting for customer_record -- a circular wait, one of the four Coffman conditions, and once both threads are in this state neither can ever proceed on its own. The general-purpose fix is lock-ordering discipline (co-18): have BOTH code paths always acquire the two locks in the SAME agreed-upon global order (e.g., always customer_record before warehouse_record), which makes the circular-wait shape structurally impossible to construct.

A plain Semaphore (co-13) has no memory of how many permits it started with -- an extra release() simply increments the internal counter past its intended ceiling with no error, silently growing the effective concurrency limit over time as the bug keeps firing. Swapping Semaphore for BoundedSemaphore (same interface, same co-13 concept) would have raised a ValueError on the very first accidental double release(), surfacing the bug immediately instead of letting it quietly erode the rate limit.

CPython's GIL happens to make many such busy-wait flags "just work" as an implementation coincidence (co-19) -- there is no LANGUAGE-level guarantee that one thread's write to ready is visible to another thread's read at any particular time, so this code's correctness is riding on an unspecified implementation detail, not a portable guarantee (and busy-waiting also burns a full CPU core doing nothing useful the whole time it spins). The correct primitive is a threading.Event (co-15) or Condition (co-14): both provide an explicit, guaranteed wake-up mechanism instead of relying on a polling loop and an unwritten assumption about visibility.

This is exactly the shared-mutable-state hazard (co-07) queue.Queue (co-21) exists to solve: a hand-rolled list used as a cross-thread hand-off channel has NONE of the internal locking a real thread-safe queue provides, so append and pop(0) can interleave unsafely, as this crash demonstrates. The deeper lesson (co-20) is "communicate by sharing queues, not by sharing memory" -- reach for the stdlib's already-safe queue.Queue for cross-thread hand-off instead of hand-rolling a shared mutable list and then bolting a lock onto it after the fact.

A Future (co-25) stores whatever exception its worker raised, but that exception is only ever RE-RAISED when something actually calls .result() on that specific Future -- if the Future is discarded unread, the stored exception is simply never surfaced anywhere, silently swallowed. The fix is to keep a reference to every submitted Future (a list works) and call .result() on each one (co-23), letting any worker exception propagate to the caller where it can be logged, retried, or handled.

requests.get(url) is a genuinely BLOCKING call -- it never awaits anything, so it never yields control back to the event loop (co-27); the coroutine holds the single OS thread the whole loop runs on for the entire duration of the network call. Every other coroutine gathered alongside it is starved until it finishes, which is why the fetches run sequentially instead of overlapping -- the fix is either an async HTTP client (one that actually awaits its I/O) or offloading the blocking call via run_in_executor/ asyncio.to_thread (co-26).

Not necessarily -- Amdahl's Law (co-28) caps the maximum possible speedup at 1 / (serial fraction) of the workload, regardless of worker count. If, say, 25% of this job's work is inherently serial (some setup or final combine step that can't be split across workers), the theoretical ceiling with ANY number of workers is 1 / 0.25 = 4x, and 10s / 4.5s ≈ 2.2x sitting below even that ceiling is plausibly explained by real per-worker overhead on top of an already-capped theoretical maximum -- "the pool is broken" is one possible explanation, but "the workload's own serial fraction already limits the ceiling" needs to be ruled out first, by measuring that serial fraction directly, before assuming a pool bug.

A Subject is a HOT Observable (co-31): it emits ticks on its own schedule the moment they're produced, regardless of whether anyone is subscribed yet, and it does NOT replay past emissions to a late subscriber. The dashboard genuinely subscribed successfully -- it simply missed the 30 seconds of ticks that were emitted before its subscription existed, which is expected hot-stream behavior, not a bug; if replay-from-start were the actual requirement, a COLD Observable (or a ReplaySubject-style variant) would be the correct choice instead.

A bigger buffer (co-32) is still a REACTIVE patch applied after the mismatch exists -- it delays the out-of-memory failure but doesn't remove the root cause, since a sufficiently slow subscriber or sufficiently long-running stream will eventually exhaust any fixed buffer size, however large. Reactive pull (co-29, co-32) removes the mismatch at its SOURCE: the subscriber explicitly states its own current demand via request(n), and the producer is contractually bound never to exceed it, so no buffer of any size is ever asked to hold more than the subscriber has already said it can handle.

Sharing the word "reactive" doesn't mean sharing a semantic model (co-33): the dashboard's Rx-style update stream models DISCRETE events over time (a series of individual pushed values, each an onNext call). Original Functional Reactive Programming (Elliott & Hudak, 1997) is built on CONTINUOUS-time behaviors -- values that conceptually exist and can be sampled at every instant, not just at discrete emission points -- plus separate discrete events. The dashboard's stream is genuinely the former, not the latter; conflating the two obscures a real semantic difference, not just a naming coincidence.

Root cause: current = stats["count"] followed by stats["count"] = current + 1 is a read-modify-write split across two lines with an explicit time.sleep(0) yield in between -- another worker can read the SAME current value before the first worker writes its result back, so both workers' increments collapse into one. Wrapping the entire read-modify-write in with guard: makes it a single atomic step no other worker can interleave into.

Run: python3 kata.py

Output (this exact count varies slightly run to run because of scheduler timing, but actual is always strictly less than expected in the before/ version, and always exactly equal in the after/ version):

expected=12000 actual=12000
kata OK (fix verified)

Root cause: the two workers acquire printer and scanner in OPPOSITE orders, and the Barrier forces both to hold their own first lock before either attempts the second -- a textbook circular wait, one of the four Coffman conditions, reproduced deterministically every run. Making BOTH workers agree to acquire printer before scanner removes the circular-wait shape entirely: with a shared first lock, only one worker can ever be mid-acquisition at a time, so there is no longer a "both hold their first lock at once" state for a cycle to form around -- which is also why the fix drops the Barrier rather than keeping it: forcing that state is now structurally impossible, not merely unnecessary.

Run: python3 kata.py

Output:

a_hung=False b_hung=False
kata OK (fix verified)

Root cause: a plain Semaphore tracks only its CURRENT permit count, with no memory of the count it started with -- an extra release() simply increments the counter with no upper bound, silently growing the effective pool size. BoundedSemaphore (same interface, same underlying idea) remembers its INITIAL count and raises ValueError the instant a release() would push the count above it, catching the bug the moment it happens instead of letting it silently corrupt the pool's real capacity.

Run: python3 kata.py

Output:

blocked: Semaphore released too many times
first=True second=True third=False
kata OK (fix verified)

Root cause: cond.wait() returns on ANY notify/notify_all() call -- it makes no promise that the FULL predicate the waiter actually cares about is now true, only that SOMETHING changed. Checking the predicate with if (once) instead of while (re-checked every time wait() returns) lets the waiter proceed on a partial, early notify. Swapping to while makes the waiter go straight back to cond.wait() whenever it wakes up and the real predicate still isn't satisfied.

Run: python3 kata.py

Output:

['baking: oven=True dough=True']
kata OK (fix verified)

Root cause: a Future's stored exception is only ever raised at the moment something calls .result() on THAT specific Future -- if nothing ever does, the exception simply never surfaces anywhere, no matter how the pool itself is shut down. Capturing the Future and calling .result() (inside a try/except when a failure is expected/handled) is the only way to actually observe a worker's exception.

Run: python3 kata.py

Output:

submitted the parse job
caught: could not convert string to float: 'n/a'
kata OK (fix verified: the ValueError was caught exactly where the caller expects it)

Root cause: time.sleep() is a real, OS-level blocking call -- it does not await anything, so the coroutine running it never yields control back to the event loop, and the loop's single OS thread is unavailable to run ANY other coroutine for the whole duration. await asyncio.sleep() is the cooperative equivalent: it suspends only the calling coroutine and returns the OS thread to the event loop, which is then free to run quick_ping in the meantime.

Run: python3 kata.py

Output:

['report: started', 'ping: started', 'ping: finished', 'report: finished']
kata OK (fix verified: the faster coroutine finished first, as intended)

Root cause: queue.Queue tracks an internal "unfinished tasks" counter, incremented once per put() and decremented only by a matching task_done() -- join() blocks until that counter reaches zero. Draining items with get_nowait() removes them from the queue's internal deque but never touches that counter, so join() waits forever even though the queue is genuinely empty. The kata demonstrates the hang safely by running q.join() on a daemon=True wrapper thread and applying join(timeout=...) to THAT wrapper thread instead (since Queue.join() itself accepts no timeout), the same bounded-detection trick used to reproduce Kata 2's deadlock without hanging the drill itself.

Run: python3 kata.py

Output:

hung=False
kata OK (fix verified)

Root cause: multiprocessing.Process runs the child in a genuinely SEPARATE address space -- every module-level variable the child process sees is its OWN private copy (created at process start), not a reference into the parent's memory, so mutating it inside the child has no way to reach the parent at all. multiprocessing.Value("i", 0) allocates the integer in OS-backed SHARED memory instead, so both the parent and every child process that receives the same Value object are genuinely reading and writing the SAME underlying memory -- and get_lock() protects the read-modify-write the same way a threading.Lock would within one process.

Run: python3 kata.py

Output:

before: counter=0
inside child: counter=1
after: counter=1
kata OK (fix verified)

Root cause: Future.cancel() can only succeed on a Future that is still PENDING -- once a worker has actually started executing it, cancel() has nothing left to prevent, so it correctly returns False without raising anything, which is exactly why the "before" version's unchecked assumption is dangerous. The fix has two parts: structurally, arrange for the Future being cancelled to genuinely still be pending (here, by using max_workers=1 so a second submitted job is forced to queue behind the first); and defensively, always check cancel()'s boolean return value rather than assuming success.

Run: python3 kata.py

Output:

cancelled=True
kata OK (fix verified)

Root cause: a single module-level dict used as "the current request" has exactly ONE request_id key, shared by every thread that touches it -- whichever thread writes LAST wins, regardless of which thread "logically" owns that write, so a fast worker's write can silently clobber a slow worker's value before the slow worker ever reads it back. threading.local() gives each thread its OWN, separate attribute namespace under the hood -- request_context.request_id resolves to a DIFFERENT underlying storage location per thread, so no thread's write can ever be visible to, or overwritten by, another thread's write to "the same-looking" attribute.

Run: python3 kata.py

Output:

{'worker_fast': 'REQ-B', 'worker_slow': 'REQ-A'}
kata OK (fix verified)

taming-state is the cross-cutting idea this topic returns to constantly: locks (co-11-14), message-passing (co-20-22), and asyncio's single-thread cooperative model (co-26-27) are three DIFFERENT strategies for the SAME underlying problem -- containing what mutable state two things can touch at once -- not three unrelated toolkits to memorize separately. Recognizing "this is taming-state again, applied a different way" is what lets a developer transfer intuition to a fourth, unfamiliar concurrency tool later, instead of starting from zero each time.

Determinism loss shows up under different names throughout this topic: memory visibility (co-19) is fragile precisely because CPython's usual determinism is an implementation coincidence, not a guarantee; livelock (co-17) is threads staying "active" while making emergent, non-progressing behavior instead of deterministic forward progress; the stress-harness example (ex-80) needs MANY repeated trials specifically because a single passing run proves nothing about race-freedom -- concurrent code's correctness cannot be verified the same way sequential code's can, by running it once and reading the output.

The Barrier in the "before" kata specifically forces BOTH workers to be holding their OWN first lock simultaneously before either attempts the second -- that state is only reachable when the two workers' first locks are genuinely DIFFERENT resources. Once both workers agree to acquire the SAME lock first (the fix), only one worker can ever be mid-acquisition at any instant, so trying to force "both hold their first lock at once" via a Barrier would create a brand NEW, self-inflicted deadlock: the second worker could never even reach the barrier, since it would be blocked acquiring the very lock the first worker is holding through its own barrier wait. The fix's guarantee is structural, not timing-dependent, and is actively incompatible with that forcing mechanism.

PEP 779 makes free-threading officially SUPPORTED starting in 3.14, but it ships as an opt-in BUILD variant (python3.14t), not the default interpreter most installations run -- the standard GIL build remains the default, and even platform installers (macOS's, specifically) still label the free-threaded option "experimental" in their own UI despite the PEP's own supported status. This topic's examples branch on sys._is_gil_enabled() at runtime precisely so they stay correct on WHICHEVER interpreter actually executes them, rather than assuming a single, universally-available build.

A data race is the narrower, mechanically-checkable case: unsynchronized concurrent access to the same memory location where at least one access is a write. A race condition is the wider, SEMANTIC category -- any bug where output depends on interleaving timing, which can occur even when every individual memory access is correctly locked, e.g. two properly-synchronized operations still running in an unintended overall order for the business logic they're meant to implement. Example 37 exists specifically to show these failing in DIFFERENT observable ways -- conflating the two terms would hide a genuinely wider bug category behind the narrower, more mechanically obvious one.

The push/pull inversion IS the entire reason Observable exists as its own abstraction, not an incidental detail of it: an Iterable's consumer actively PULLS ("give me your next value, right now") on the consumer's own schedule, while an Observable's producer actively PUSHES ("here's a value, whenever I have one") on the PRODUCER's own schedule. That inversion is exactly what makes Observable suited to inherently producer-driven sources -- user clicks, sensor readings, price ticks -- that a pull-based Iterable cannot represent at all, since there's no way to "pull" an event that hasn't happened yet.

Reactive streams apply the SAME shared-state and flow-control discipline this topic already builds (co-07's shared-mutable-state hazard, co-22's backpressure) but wrapped in a genuinely different execution and composition model -- push-based, operator-composed, delivered via a third-party library (reactivex) rather than the stdlib every other example in this topic uses. Grouping it at the end lets a reader master the CORE concurrency model on solid, dependency-free stdlib ground first, then transfer that same discipline onto an unfamiliar API shape and a new third-party dependency, instead of learning both a new concept and a new library's installation/API surface at the same time throughout.

Amdahl's Law gives a concrete, falsifiable CEILING derived from a workload's own serial fraction -- without naming it, a team burning effort tuning worker-pool sizes has no way to distinguish a fixable inefficiency from an ALREADY near-optimal result given how much of the work is inherently serial (AP9's exact scenario: 4 workers landing at 2.2x, not 4x, might simply be close to a workload's own 4x ceiling, not a broken pool). Naming and computing the law turns "just add more workers" from a hopeful guess into a measurable, boundable prediction a team can check their actual results against.