If tasks in a runtime switch only at explicit suspension points and share one carrier thread, can you still get race conditions? Explain what is and is not guaranteed.

## Two kinds of race A **data race** is a memory-model concept: two concurrent accesses to the same location, at least one a write, without ordering between them. Consequences are ugly and low level — torn values, indefinitely stale reads, reordering surprises. A **race condition** in the broader sense is a correctness bug where the outcome depends on interleaving. An **atomicity violation** is the common shape: a sequence of operations that must appear indivisible is interrupted partway. Cooperative single-threaded scheduling eliminates the first and leaves the second fully intact. Candidates who answer "single-threaded, so no races" are answering only the first. ## What single-threaded cooperative scheduling does guarantee Between two suspension points, a task runs to completion with respect to other tasks on the same carrier thread. That is a real and useful guarantee: you can mutate a shared map across many lines with no lock, provided none of those lines suspends. It also means interleaving points are *finite and visible* — a reviewer can find them by looking for suspension markers, unlike preemptive threading where every instruction is a potential switch. ## What it does not guarantee **Check-then-act across a pause.** The classic: ``` if (!cache.contains(key)): # check value = await fetch(key) # <-- everything else runs here cache.put(key, value) # act on a stale check ``` Two tasks can both pass the check and both fetch. You get duplicate work, duplicate side effects, or a last-writer-wins overwrite. The fix is the same as with locks: record the in-flight operation itself (store a pending placeholder before awaiting so the second caller joins it) or serialise with an async-aware mutual-exclusion primitive. **Broken invariants observed at a pause.** If you take an object out of a consistent state, suspend, then finish the update, other tasks observe the inconsistent middle. Rule: never suspend while an invariant is broken; do all awaits before or after the mutation, not inside it. **Re-entrancy.** A handler that suspends can be entered again for a new event before the first completes. Any per-handler mutable state (a module-level accumulator, a "currently processing" flag) is now shared between two live activations. **Ordering assumptions.** Completions are delivered in whatever order the underlying operations finish, not in the order they were started. Code that assumes responses arrive in issue order is racing. **External state.** Time-of-check to time-of-use against a database, a file, or another service is unaffected by your scheduler. Only the external system's own atomicity (transactions, conditional writes, compare-and-set) helps there. **Cancellation.** Cancelling a task usually takes effect at its next suspension point, so a task can be cancelled in the middle of a multi-step update. Anything that must complete atomically has to be shielded or made idempotent. ## When multiple carrier threads enter Many runtimes multiplex tasks over a pool of carrier threads. Then two tasks genuinely execute at the same instant, and the memory-model hazards return in full: you need proper synchronisation and safe publication for shared mutable state, exactly as with threads. Worse, code may have been written and tested under a single-threaded assumption and only break when the pool is widened or when the deployment enables parallelism. Treating "single-threaded" as an architectural invariant means enforcing and documenting it, not assuming it. Even on one carrier thread, a task can resume on a *different* thread if the runtime allows, which invalidates thread-affine constructs: thread-local storage read after an await may belong to another logical task, and a lock acquired before a suspension may be released by a different thread than acquired it — undefined or illegal for many lock implementations. So: do not hold a thread-affine lock across a suspension point. ## The mental model to carry into an interview Say it in one line: *cooperative scheduling turns "anywhere" into "here", it does not turn "anywhere" into "nowhere"*. It shrinks the set of interleaving points to something you can enumerate and audit, which is a genuine engineering win — and the discipline it demands is to look at every suspension point and ask what invariant is currently broken and what other task could touch it.