Don’t walk blindly into a deadly embrace…
Our world is built on modular, composable software. We routinely expect that we don’t need to know about the internal implementation details of a library or plug-in to be able to use it correctly.
The problem is that locks, and most other kinds of synchronization we use today, are not modular or composable. That is, given two separately authored modules, each of which is provably correct but uses a lock or similar synchronization internally, we generally can’t combine them and know that the result is still correct and will not deadlock. There are only two ways to combine such a pair of lock-using modules safely: …
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 |
Hello,
In the section “Avoidance: Noncritical Calls”, option (a) says “move the call out of the critical section if you didn’t need the exclusion anyway.” Is this a reliable option? Afterall, the compiler can reorder code INTO a critical section (just not out of a critical section) as outlined in your previous article, “Use Critical Sections (Preferably Locks) to Eliminate Races.”
Thanks for your time.
Cheers