Questions: The Critical Section Problem and Race Conditions

Question 1

Two threads each increment a shared counter 1,000,000 times starting from 0. After both threads finish, the final value is 1,756,432 instead of 2,000,000. What is the most likely explanation?

• A. The CPU made arithmetic errors on some additions
• B. A race condition occurred: the load-modify-store sequence is not atomic, so some increments from one thread overwrote increments from the other
• C. The threads ran sequentially, so only one completed its full million iterations
• D. Integer overflow caused some counts to wrap around

Answer: (B)

The operation `counter++` compiles to three hardware steps: load the current value, add 1, store the result. If Thread A loads 5, then Thread B also loads 5 before A stores its result, both store 6 — losing one increment. With millions of iterations, these lost updates accumulate to an unpredictable deficit. This is the classic race condition: a result that depends on the interleaving of non-atomic operations.

Question 2

A C++ programmer declares a shared counter as volatile to fix a race condition between two threads incrementing it. Will this solve the problem?

• A. Yes — volatile forces all reads and writes to go directly to memory, preventing stale values
• B. Yes — volatile makes operations on the variable atomic
• C. No — volatile only prevents the compiler from caching the variable in a register; it does not make the load-modify-store sequence atomic
• D. No — volatile makes the problem worse by disabling all compiler optimizations

Answer: (C)

volatile tells the compiler not to cache the variable in a register and to re-read it from memory on every access. It does NOT make compound operations like `counter++` atomic — the three-step load/modify/store sequence remains interruptible. A thread switch can still occur between the load and the store, allowing another thread to overwrite the value. Proper fixes use atomic types, mutexes, or hardware-supported atomic instructions.

Question 3

A correct solution to the Critical Section Problem must guarantee mutual exclusion, progress, and bounded waiting — satisfying just two of the three is insufficient.

• T. True
• F. False

Answer: True

All three requirements are necessary. Mutual exclusion prevents two threads from being in the critical section simultaneously. Progress ensures the system doesn't deadlock when threads want to enter. Bounded waiting ensures no thread starves indefinitely. A solution providing mutual exclusion but allowing starvation (violating bounded waiting) is incorrect; so is one preventing deadlock but occasionally allowing simultaneous access (violating mutual exclusion).

Question 4

Race conditions are easy to detect in testing because they generally produce a clearly wrong result or cause the program to crash.

• T. True
• F. False

Answer: False

Race conditions are notoriously difficult to detect precisely because they manifest intermittently. The outcome depends on the timing of thread interleaving, which varies with CPU load, scheduling decisions, and other environmental factors. A program with a race condition may run correctly thousands of times before the interleaving that exposes the bug occurs — and may never reproduce the bug in a controlled testing environment, even though it fails in production under load.

Question 5

Why does declaring a variable as volatile in C/C++ not fix a race condition on a shared counter?

Model answer: volatile prevents the compiler from caching a variable in a register, but it does not make operations on the variable atomic. The increment `counter++` still compiles to three separate hardware steps (load, add, store), and a thread switch between any two steps allows another thread to overwrite the result.

The root cause of the race condition is that counter++ is not a single indivisible operation at the hardware level — it is read-modify-write. volatile only controls compiler behavior (preventing register caching), not the hardware's ability to interleave these steps across threads. Fixing a race condition requires atomicity, which comes from hardware atomic instructions (like compare-and-swap), mutex locks, or std::atomic in C++.