Base CS from zero
Time and concurrency: multiple-choice review
Crux Multiple-choice synthesis across the time-and-concurrency unit — async, blocking vs non-blocking, the event loop, concurrency vs parallelism, and the race conditions that appear once tasks share state.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skySix questions that cut across the whole unit. Each one is a prediction or a decision you would make about a real running program — not a definition to recite, but the reasoning the lessons built toward, pushed one step further into where tasks share state.
Goal
Confirm you can connect the unit’s spine — why async exists, blocking vs non-blocking, the event loop’s one rule, and concurrency vs parallelism — and reason about what happens when interleaved or parallel tasks touch the same data.
Quiz
Completed
A web server reads a file from disk on every request. Switching from a blocking read to a non-blocking one makes that disk read take how long, and what actually improves?
Heads-up Non-blocking changes nothing about the device. The disk still takes its 10 ms either way. All that changes is whether the CPU is frozen during the wait (blocking) or free to do other work (non-blocking).
Heads-up They behave very differently. A blocking call keeps its stack frame stuck on the stack until the work finishes, freezing the program; a non-blocking call returns immediately and delivers the result later via a callback.
Heads-up It does not fail. A non-blocking call hands the request to the device and returns at once; the result is delivered later through the callback, once the device finishes.
Quiz
Completed
A program runs: console.log('A'); setTimeout(cb, 0) where cb prints 'B'; then console.log('C'). What does it print, and what is the underlying rule?
Heads-up The 0 sets the queueing delay, not the run time. B is placed on the callback queue, but the event loop will not run it until the call stack is empty — which only happens after the synchronous A and C have printed.
Heads-up Callbacks never preempt synchronous code. A queued callback waits for the stack to empty; synchronous code always finishes first. There is no priority that lets a callback interrupt a running line.
Heads-up The event loop is single-threaded — one core, one thing at a time. B is late because of the empty-stack rule, not because it ran on another core. Nothing here runs in parallel.
Quiz
Completed
A program is structured as one task with one thread. You run it on a 16-core machine. How fast is it, and why?
Heads-up A single thread is one ordered stream of instructions — it cannot be split across cores. Extra cores stay idle unless the program is structured into multiple threads or tasks. Structure must come before parallelism.
Heads-up More cores never make a program parallel on their own. Parallelism requires the work to be split into multiple tasks first; a single-task, single-thread program runs on one core no matter how many exist.
Heads-up One task uses one core; the other 15 are simply unused, not coordinated. There is no coordination overhead because there is nothing to coordinate — the program is exactly as fast as on a single-core machine.
Quiz
Completed
A single-core machine interleaves 50 tasks with an event loop. How many run at the same instant, and is this concurrency or parallelism?
Heads-up Concurrency means taking turns, not true simultaneity. One core is one fetch-decode-execute engine and runs exactly one instruction at a time. At any instant only one of the 50 tasks is actually running.
Heads-up The event loop is concurrency, not parallelism. It runs one callback to completion before starting the next, all on a single core. Parallelism needs multiple cores; an event loop on one core never has two tasks running in the same instant.
Heads-up Interleaving means one is running while the others wait their turn. At every instant exactly one task is executing on the core; the others are paused, not all stopped.
Quiz
Completed
Two threads on two cores each run counter = counter + 1 a million times on one shared counter, with no synchronization. The final value is often far below two million. Why?
Heads-up counter = counter + 1 is not atomic — it is a read, an add, and a write. Two threads can interleave between those sub-steps, both read the same value, and one write clobbers the other. The lost updates are real, not a measurement error.
Heads-up Both cores can read and write the same shared memory — that is exactly the problem. Nothing is rejected; updates are lost because two reads of the same old value lead to two writes of the same new value, when there should have been two distinct increments.
Heads-up The event loop is single-threaded concurrency. This scenario is two real threads on two cores running in parallel — there is no single event loop serialising them. Genuine parallel access to shared state is what makes the race possible.
Quiz
Completed
A team adds a lock so only one thread can run the counter-update at a time. The race disappears, but throughput drops on the 8-core machine. How should you read this?
Heads-up No lock can do both. A lock works precisely by forcing threads to take turns through the protected section, which is serial by definition. The throughput cost is the price of correctness; you reduce it by locking less, not by expecting a lock to run in parallel.
Heads-up A lock has a real cost: it turns a parallel section into a serial one, so threads queue for it. The more time spent inside the lock, the less parallelism remains. The slowdown is a direct, expected consequence of locking.
Heads-up Removing the lock brings the race straight back; more cores make a race worse, not better, because more threads contend for the same unprotected data. The correct lever is to minimise the shared, locked region while keeping the lock for correctness.
Recap
The unit’s through-line is one idea taken to its edge: the CPU is fast and devices are slow, so programs use async — non-blocking calls plus callbacks — and an event loop that runs one callback at a time, only when the call stack is empty. That is concurrency: many tasks interleaved on one core, taking turns. Parallelism is different — tasks truly running at the same instant on multiple cores — and it only helps once the work is structured into tasks. The moment those tasks share state, a race condition becomes possible: a step like counter = counter + 1 is really read-add-write, and parallel threads can interleave to lose updates. A lock restores correctness by serialising the shared section — at the cost of the very parallelism it protects. Correctness first, then minimise what must be serial.