The same updates can differ when reads and writes interleave.
Writing each read and write as a separate step lets one finite schedule expose a lost update while a serialized schedule preserves both changes.
What disappears when two updates read the same shared balance before either finishes?
- Separate each transaction read from its later write
- Recognize a write computed from a stale shared value
- Enumerate the exact step order of a finite schedule
- Compare a lost-update result with a serialized result
The deposit adds 10 and the withdrawal subtracts 20. In the first schedule, both operations read 100. The deposit writes 110, but the withdrawal still computes from its earlier read and writes 80. The later write replaces the deposit result, so the final balance does not contain both changes.
The second schedule lets the deposit read and write before the withdrawal reads. The withdrawal therefore sees 110 and writes 90. These programs enumerate two selected finite schedules and their exact final balances.
- Output
- —
- Value
- —
- Diagnostic
- —
The first program returns ((deposit read 100) (withdraw read 100) (deposit write 110) (withdraw write 80) (final 80)). The serialized program returns ((deposit read 100) (deposit write 110) (withdraw read 110) (withdraw write 90) (final 90)).
Follow the two initial balance reads before either assignment in the first run, then locate the writes of 110 and 80. In the second run, the withdrawal read follows the write of 110. The execution traces record both explicit schedules under fixed runtime limits.
Change the program and compare the result.
In the first schedule, place the withdrawal write before the deposit write. Predict the final balance and name the update that is then lost.
Show hint
Both writes were computed from 100, so the write that occurs last determines the final balance.