Base CS from zero
Time and concurrency: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recalling is what makes the idea stick. These cover the whole unit, ending where the lessons pointed: what happens once concurrent tasks share data.
Reconstruct the unit’s spine from memory — why async exists, the blocking/non-blocking split, the event loop’s one rule, the concurrency-vs-parallelism distinction, and why shared state forces synchronization — without looking back at the lessons.
- 01Why does async exist? Use the CPU-vs-device speed gap in your answer.
- 02What is the difference between a blocking and a non-blocking call, and what is a callback for?
- 03What is the event loop, and what single rule governs when a callback runs?
- 04What is the difference between concurrency and parallelism, and why can a single-core machine be concurrent but never parallel?
- 05What is a race condition, and why does counter = counter + 1 across two threads expose one?
- 06What does a lock do to fix a race, and what is the cost of using one?
If you could reconstruct each answer from memory, you hold the unit’s spine: async exists because the CPU must not sit idle across the huge CPU-vs-device speed gap; a non-blocking call returns immediately and delivers its result later through a callback; the event loop runs callbacks one at a time, only when the call stack is empty, so synchronous code always finishes first. That is concurrency — interleaving on one core, taking turns — as opposed to parallelism, true simultaneity on multiple cores. And the moment concurrent tasks share state, order matters: a race condition can lose updates because read-add-write is not atomic, and a lock restores correctness by serialising the shared section at the cost of its parallelism.