Two of the ideas you practise, meeting in one real situation. Choose, see what actually happens, then reflect.
A case · you decide
Trice and Baton lose an update Trice & Baton — a 17-year-old debugging a like-counter in a club project
The idea in play: counter += 1 is three steps (read, add, write), and the order the tasks run in can lose one update.
Two tasks each run counter += 1 once, starting from 0. Sometimes the counter ends at 2, and sometimes at 1.
Trice: each += is read, add, then write.
Baton: the two tasks' reads and writes can interleave in any order.
What is the smallest final value possible?
0 1 2, always
Why would this bug pass most tests?
A race is not about speed. It is about the order steps happen in.
A race is not about speed. It is about the order steps happen in.
Show your working: the order that loses an update Task A reads the counter: 0. counter 0 · A's copy 0 · B's copy 0. Task A adds 1 in its own copy: 1. counter 0 · A's copy 1 · B's copy 0. Task B reads the counter: 0. counter 0 · A's copy 1 · B's copy 0. Task A writes 1 back. counter 1 · A's copy 1 · B's copy 0. Task B adds 1 in its own copy: 1. counter 1 · A's copy 1 · B's copy 1. Task B writes 1 back. counter 1 · A's copy 1 · B's copy 1. the lost update: B writes 1 over the 1 task A already wrote. The counter ends at 1. Two increments ran and one was lost, because both tasks read 0 before either wrote. Who made this? “In reality, every technology reflects decisions made by designers, companies, and communities, and carries the values and power of those choices.”
Who benefits from this technology? Whose needs are ignored? Who made this? “In reality, every technology reflects decisions made by designers, companies, and communities, and carries the values and power of those choices.”
Who benefits from this technology? Whose needs are ignored? Race two tasks →
A case · you decide
Sheara and Isla fix the counter Isla & Sheara — a 16-year-old choosing a fix for the same race
The idea in play: shared, mutable state is where races live; an actor serialises access so only one task touches it at a time.
The counter is shared between two tasks and both change it. Isla's teammates suggest three fixes.
Sheara names the problem: the state is shared AND mutable.
Isla's tool is the actor: whatever lives inside it is touched by one task at a time, each change finishing before the next starts.
Which fix is correct?
Add a short sleep before each increment Give each task its own copy of the counter Put the counter in an actor so the two increments cannot overlap
Why doesn't a sleep fix a race?
Fix the sharing, not the timing.
Fix the sharing, not the timing.
Show your working: the counter inside an actor Task A reads the counter: 0. counter 0 · A's copy 0 · B's copy 0. Task A adds 1 in its own copy: 1. counter 0 · A's copy 1 · B's copy 0. Task A writes 1 back. counter 1 · A's copy 1 · B's copy 0. Task B reads the counter: 1. counter 1 · A's copy 1 · B's copy 1. Task B starts only after Task A has written. Task B adds 1 in its own copy: 2. counter 1 · A's copy 1 · B's copy 2. Task B writes 2 back. counter 2 · A's copy 1 · B's copy 2. The counter ends at 2, and it ends at 2 in every order the actor allows. Who made this? “In reality, every technology reflects decisions made by designers, companies, and communities, and carries the values and power of those choices.”
Who benefits from this technology? Whose needs are ignored? Who made this? “In reality, every technology reflects decisions made by designers, companies, and communities, and carries the values and power of those choices.”
Who benefits from this technology? Whose needs are ignored? Race two tasks →