… The only way to eliminate such a potential deadlock is to make sure that all mutexes ever held at the same time are acquired in a consistent order. But how can we ensure this in a way that will be both usable and correct? For example, we could try to figure out which groups of mutexes might ever be held at the same time, and then try to define pairwise ordering rules that cover each possible combination. But that approach by itself is prone to accidentally missing unexpected combinations of locks; and even if we did it perfectly, the result would still be at best "DAG spaghetti"—a directed acyclic graph (DAG) that nobody could comprehend as a whole. And every time we want to add a new mutex to the system, we would have to find a way fit it into the DAG without creating any cycles.
We can do better by directly exploiting the knowledge we already have about the structure of the program to regularize the mess and make it understandable. …
|July 2007||The Pillars of Concurrency|
|August 2007||How Much Scalability Do You Have or Need?|
|September 2007||Use Critical Sections (Preferably Locks) to Eliminate Races|
|October 2007||Apply Critical Sections Consistently|
|November 2007||Avoid Calling Unknown Code While Inside a Critical Section|