The latest Effective Concurrency column, “Interrupt Politely”, just went live on DDJ’s site, and will also appear in the print magazine. From the article:
Violence isn’t the answer.
We want to be able to stop a running thread or task when we discover that we no longer need or want to finish it. As we saw in the last two columns, in a simple parallel search we can stop other workers once one finds a match, and when speculatively running two alternative algorithms to compute the same result we can stop the longer-running one once the first finds a result. [1,2] Stopping threads or tasks lets us reclaim their resources, including locks, and apply them to other work.
But how do you stop a thread or task you longer need or want? Table 1 summarizes the four main ways, and how they are supported on several major platforms. Let’s consider them in turn. …
I hope you enjoy it.
Finally, here are links to previous Effective Concurrency columns (based on the dates they hit the web, not the magazine print issue dates):
| 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 |
| December 2007 | Use Lock Hierarchies to Avoid Deadlock |
| January 2008 | Break Amdahl’s Law! |
| February 2008 | Going Superlinear |
| March 2008 | Super Linearity and the Bigger Machine |
| April 2008 | Interrupt Politely |
Sutter’s Mill 
While killing off a single thread among many in a process is a bad idea for reasons you pointed out, killing off an entire process (among many in an application) can be OK. Most applications need to deal with the case that at any point in time, the OS or computer can crash, and the application has to recover. So,
in a reliable application, if your application is partitioned across multiple processes, killing an individual process can be an acceptable recovery strategy.
Just because you acquired the mutex, doesn’t mean the last
operation holding the mutex completed!
Thanks for a very interesting article.
An additional note to this is that concurrent programming is invasive in the sense that if you’re writing code that will be re-used, you must prepare for it to be called asynchronously and provide cancellation points.
I’m reminded of the photo management application IMatch, where the author struggled to make the slideshow responsive since the image-loading libraries didn’t provide cancellation points, meaning that once it starts loading that 300MB RAW file, you’re not getting anything else loaded until it is done.
I predict that it will be some time before we have a software library stack that is tailored to concurrent use.