Chapter 8: Lock Debugging
Imagine this: two threads, T1 and T2, running on different CPU cores, concurrently work upon a shared (global) writable data item. If one (or both) of these memory accesses is a write (a store), then congratulations, you've just witnessed a wily difficult-to-spot-and-catch bug or defect: a data race. This can happen in both user as well as kernel space. In the latter, the possibility of racing with both process (thread) and interrupt contexts arises as well.
A data race is a bug of course. What's worse, it's often a clue, or symptom, to the fact that there's often a higher-level issue or defect (like the proverbial tip of the iceberg). Untangling buggy code, finding the data race, fixing it (and finding any higher-level root defect) is necessary! As will be covered in detail, data races occur when a critical section in the code path is left unprotected. So how do you protect the critical section? Locking is one common way to do so (the...
