Effective Concurrency: Use Critical Sections (Preferably Locks) to Eliminate Races

"In a race, no one can hear you scream."

That’s my tagline for the third Effective Concurrency column, "Use Critical Sections (Preferably Locks) to Eliminate Races." It just went live on DDJ’s site, and will also appear in the print magazine.

This article focuses on two main things:

The detailed facts of life about why most or all bets are off if you have a data race. You really, really, really don’t want to have any races in your code.
The commonality that unifies all synchronization constructs you’ve ever used or will use, from locking to lock-free styles to fences to transactional memory.

Here’s the article’s intro:

Everyone knows the basics of how to use locks:

mut.lock(); // acquire lock on x
… read/write x …
mut.unlock(); // release lock on x

But why do locks, lock-free styles, and other synchronization techniques work at all, never mind interoperate well with each other and with aggressive optimizers that transform and reorder your program to make it run faster? Because every synchronization technique you’ve ever heard of must express, and every optimization that may ever be performed must respect and uphold, the common fundamental concept of a critical section. …

I hope you enjoy it.

Next month’s article is already in post-production. It follows directly from this one, and will be titled "Apply Critical Sections Consistently." I’ll blog here when it hits the web about a month from now.

Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):

August 2007: How Much Scalability Do You Have or Need?
July 2007: The Pillars of Concurrency

Published by Herb Sutter