Module 2 · Unit 6 · Discussion 6
Anatomy of a Race Condition
Synchronization bugs are among the most difficult defects in software engineering. They are non-deterministic, they often vanish under a debugger, and they may manifest only once in a million runs — usually in production. This discussion asks you to choose a real synchronization bug from a public source, reconstruct the interleaving that triggers it, and explain what the bug teaches about the design of concurrent systems.
01 Overview
| Course | COMP 3150 / CMIS 3150 — Operating Systems |
|---|---|
| Unit | Unit 6 — Synchronization |
| Weight | Part of the 5% participation grade (each discussion is worth approximately 0.4% of the final grade) |
| Opens | Monday of Week 6 |
| Initial post due | Thursday of Week 6, 23:59 |
| Peer replies due | Sunday of Week 6, 23:59 |
| Format | One initial post (550–750 words, including an annotated interleaving or pseudocode) and at least two substantive peer replies (150–250 words each) |
| CLOs assessed | CLO3, CLO6, CLO7 |
02 Learning outcomes addressed
By participating in this discussion you will
- Explain concurrency problems and the conditions under which they occur (U6.1).
- Identify race conditions and explain the interleavings that trigger them (U6.2).
- Apply synchronization mechanisms — mutexes, semaphores, condition variables — to correct a bug (U6.3).
- Design a synchronization solution that is free of race conditions, deadlock, and starvation (U6.4).
- Evaluate Linux synchronization solutions and explain the trade-offs between correctness and performance (U6.5).
This discussion assesses CLO3 (analyse scheduling, synchronization, and deadlock solutions), CLO6 (apply Linux systems programming), and CLO7 (evaluate operating-system technologies).
03 Discussion prompt
A race condition is a situation in which the output of a computation depends on the non-deterministic timing or interleaving of concurrent operations on shared state. Race conditions are the cause of some of the most expensive software failures in history — the Therac-25 radiation-therapy accidents, the Mars Pathfinder priority inversion, and numerous security vulnerabilities in operating systems, databases, and web frameworks.
Your task
-
Choose a real synchronization
bug from a public source. Good sources include:
- A CVE (Common Vulnerabilities and Exposures) entry that describes a race condition, use-after-free, time-of-check-to-time-of-use (TOCTOU) flaw, or deadlock.
- A well-documented incident such as the Mars Pathfinder priority inversion, the Therac-25 accidents, or the Northeast blackout of 2003 (for the alarm-system race).
- A bug report in the Linux kernel, PostgreSQL, the Java runtime, or another widely used system, with the fix commit included in the report.
-
Describe the bug in enough detail that a reader
who has not seen it before can understand it.
State clearly:
- What the system was supposed to do.
- What the shared state was, and which operations accessed it.
- The interleaving (the sequence of operations across threads or processes) that triggers the bug. Present it as a numbered timeline or a short pseudocode trace.
- The consequence of the bug (data corruption, crash, security breach, or something else).
- Classify the bug. Is it a race condition, a deadlock, a livelock, or a starvation? If it is a deadlock, identify which of the four necessary conditions was violated (or, in the buggy version, satisfied). If it is a race, identify which of the three race conditions (shared state, at least one write, no synchronization) held.
- Explain the fix. What did the developers change? What synchronization primitive did they introduce, or what design did they change? Why does the fix eliminate the bug?
-
Reflect on what the bug teaches about the
design of concurrent systems. Consider:
- Why was the bug not caught during testing? What makes race conditions non-deterministic?
- What design or coding discipline would have prevented the bug in the first place?
- How do real systems (Linux, databases, browsers) try to catch or prevent this class of bug? (For example, lock-order validators like
lockdep, race detectors like Helgrind and ThreadSanitizer, or design patterns like single-writer or actor models.)
Your post should be 550–750 words, with the interleaving or pseudocode included. Cite the source of the bug (the CVE, the incident report, or the bug tracker URL) and at least one additional source (a textbook section, a paper, or a documentation page) that connects the bug to the general principle it illustrates.
04 Examples to consider
You are not limited to the examples below, but they are well documented and illustrate the range of synchronization bugs.
4.1 Mars Pathfinder (1997)
The Pathfinder lander experienced repeated system resets on Mars. The cause was a priority inversion: a low-priority meteorological task held a mutex that a high-priority bus-management task needed; a medium-priority communications task preempted the low-priority task, so the high-priority task was blocked indefinitely. The watchdog timer fired and reset the spacecraft. The fix was to enable priority inheritance on the mutex. This is one of the clearest real-world examples of a synchronization bug with a precisely understood cause and fix.
4.2 Therac-25 (1985–1987)
The Therac-25 radiation-therapy machine delivered massive overdoses to several patients because of a race condition between the operator's input and the machine's control software. When the operator entered a command quickly, the software could proceed before the machine's hardware had been configured correctly. The bug was not caught in testing because the timing was difficult to reproduce. This incident is a canonical case study in safety-critical software and in the limits of testing for concurrency bugs.
4.3 CVE-2016-5195 ("Dirty COW")
A race condition in the Linux kernel's copy-on-write mechanism allowed a local attacker to write to read-only memory. The bug was present in the kernel for nine years before it was discovered. It is a good example of a race condition in a heavily used system, and it shows that even mature code can contain concurrency bugs that survive years of testing.
4.4 CVE-2014-9295 (NTP ntpd)
A buffer overflow in ntpd was reachable
because of a race condition in the way the daemon
handled incoming packets. The bug illustrates how
race conditions often combine with other classes of
defects (here, memory safety) to produce an
exploitable vulnerability.
4.5 Other sources
The CVE database (cve.mitre.org) and the National Vulnerability Database (nvd.nist.gov) both allow searching for race conditions, TOCTOU, use-after-free, and deadlock. Bug trackers for open-source projects (the Linux kernel Bugzilla, the PostgreSQL bug tracker, the OpenJDK bug tracker) contain many well-documented examples with fixes.
05 Grading rubric
The discussion is marked out of 100 points. The criteria and their weights are given below.
| Criterion | Weight |
|---|---|
| Post quality (bug analysis, interleaving, fix, reflection) | 40% |
| Peer response quality | 30% |
| Engagement and timeliness | 20% |
| Netiquette and clarity | 10% |
5.1 Post quality (40 points)
| Level | Descriptor |
|---|---|
| Exemplary (90–100%) | A real synchronization bug from a public source, described clearly and in sufficient detail. The interleaving that triggers the bug is presented as a numbered timeline or a pseudocode trace. The bug is correctly classified (race, deadlock, livelock, or starvation), and the relevant conditions are identified. The fix is explained correctly. The reflection connects the bug to the general principles of concurrent design and to the tools that real systems use to prevent it. Sources are cited. |
| Proficient (80–89%) | A real synchronization bug, described clearly. The interleaving is presented but may be incomplete. The bug is classified correctly. The fix is explained. The reflection is present but brief. |
| Developing (70–79%) | A synchronization bug is described, but the description is vague or the interleaving is missing. The classification is incorrect or missing. The fix is described without explaining why it works. The reflection is superficial. |
| Beginning (60–69%) | The bug is not a real one (it is invented or generic), or the description is inaccurate. The interleaving, the classification, and the fix are all missing or incorrect. |
| Not demonstrated (<60%) | The post is missing, off-topic, or a restatement of the prompt without a real bug. |
5.2 Peer response quality (30 points)
The descriptors are the same as for Discussion 1. An exemplary reply might:
- Identify a similar bug in a different system and compare the two.
- Challenge the classmate's classification of the bug, with a concrete argument.
- Suggest an additional reflection: what the bug reveals about the limits of testing, code review, or verification.
5.3 Engagement and timeliness (20 points)
The descriptors are the same as for Discussion 1.
5.4 Netiquette and clarity (10 points)
The descriptors are the same as for Discussion 1.
06 Resources
- Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapters 6–7 (Synchronization Tools and Examples).
- Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapters 28–31 (Locks, Condition Variables, Semaphores).
- Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 2 (Interprocess Communication) and Chapter 6 (Deadlock).
- Herlihy, M., & Shavit, N. The Art of Multiprocessor Programming, 2nd ed. Morgan Kaufmann, 2020.
- Leveson, N. G., & Turner, C. S. An Investigation of the Therac-25 Accidents. IEEE Computer, 1993.
- Jones, M. B. What Really Happened on Mars? (A description of the Pathfinder priority inversion, available online.)
- CVE database: cve.mitre.org, and the National Vulnerability Database: nvd.nist.gov.
- Linux man-pages:
man 3 pthread_mutex_lock,man 3 pthread_cond_wait,man 3 sem_wait,man 7 pthreads,man 7 futex. - Serebryany, K., & Iskhodzhanov, T. ThreadSanitizer: Data Race Detection in Practice. Workshop on Binary Instrumentation and Applications, 2009.