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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access