This month’s Effective Concurrency column, “Break Up and Interleave Work to Keep Threads Responsive”, is now live on DDJ’s website.
Sorry for the long title; suggestions welcome. I always try to word the title to make it (a) short, (b) active, and (c) advice, but sometimes I’ll settle for two of those, or just one, until a better suggestion comes along.
From the article:
What happens when this thread must remain responsive to new incoming messages that have to be handled quickly, even when we’re in the middle of servicing an earlier lower-priority message that may take a long time to process?
If all the messages must be handled on this same thread, then we have a problem. Fortunately, we also have two good solutions, both of which follow the same basic strategy: Somehow break apart the large piece of work to allow the thread to perform other work in between, interleaved between the chunks of the large item. Let’s consider the two major ways to implement that interleaving, and their respective tradeoffs in the areas of fairness and performance.
I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns:
The Pillars of Concurrency (Aug 2007)
How Much Scalability Do You Have or Need? (Sep 2007)
Use Critical Sections (Preferably Locks) to Eliminate Races (Oct 2007)
Apply Critical Sections Consistently (Nov 2007)
Avoid Calling Unknown Code While Inside a Critical Section (Dec 2007)
Use Lock Hierarchies to Avoid Deadlock (Jan 2008)
Break Amdahl’s Law! (Feb 2008)
Going Superlinear (Mar 2008)
Super Linearity and the Bigger Machine (Apr 2008)
Interrupt Politely (May 2008)
Maximize Locality, Minimize Contention (Jun 2008)
Choose Concurrency-Friendly Data Structures (Jul 2008)
The Many Faces of Deadlock (Aug 2008)
Lock-Free Code: A False Sense of Security (Sep 2008)
Writing Lock-Free Code: A Corrected Queue (Oct 2008)
Writing a Generalized Concurrent Queue (Nov 2008)
Understanding Parallel Performance (Dec 2008)
Measuring Parallel Performance: Optimizing a Concurrent Queue (Jan 2009)
volatile vs. volatile (Feb 2009)
Sharing Is the Root of All Contention (Mar 2009)
Use Threads Correctly = Isolation + Asynchronous Messages (Apr 2009)
Use Thread Pools Correctly: Keep Tasks Short and Nonblocking (Apr 2009)
Eliminate False Sharing (May 2009)
Break Up and Interleave Work to Keep Threads Responsive (Jun 2009)
Sutter’s Mill 
It also looks like all the asterisks in the type names are missing. e.g., I assume “LongHelper helper_ = nullptr” should be “LongHelper * helper_ = nullptr”. (I’m assuming this isn’t a change in C++0x that I’ve missed.)
Thanks for the great articles. :)
Neilhendo: Thanks for the heads-up that stuff got unusually garbled this time. How strange.
Here’s the forensic report: The extraneous “do”, “3(a)”, and “sitaution” are my own typos in the original manuscript. The missing “)” crept in during copyediting of the PDF magazine-style layout that goes to subscribers and I didn’t notice they dropped it when I reviewed the proofs. The rest somehow crept in after that when they used the PDF draft to create the online version. I’ll ask them to fix it. Thanks again.
Some more small typos (couldn’t find a way to edit my previous post):
Example 1(a):
Missing “)” from this line:
if( helper == nullptr
I think “start+” should be “start+i” in this line:
for( ; i < ChunkSize && start+ < items.size(); ++i ) {
Example 2(b):
helper- 1 ) do {
Also in the second Example 3(a) – should that be 3(b)?
while( n– > 0 ) do {
(Unless I’m missing some while syntax changes in C++0x?)
On p.4:
“sitaution” in:
“In that kind of sitaution, beware the possibility of starvation.”
Hope that doesn’t seem nit-picky… just figured you’d want to know. :-)
Thanks – great and useful as always. Looks like a small typo in the “Example: Breaking Up a Potentially Long-Running Operation” on the first page:
helper-<render( items[i] );