Effective Concurrency: Use Threads Correctly = Isolation + Asynchronous Messages

This month’s Effective Concurrency column, “Use Threads Correctly = Isolation + Asynchronous Messages”, is now live on DDJ’s website.

From the article:

Explicit threads are undisciplined. They need some structure to keep them in line. In this column, we’re going to see what that structure is, as we motivate and illustrate best practices for using threads — techniques that will make our concurrent code easier to write correctly and to reason about with confidence.

I hope you enjoy it. Finally, here are links to previous Effective Concurrency columns and the DDJ print magazine issue in which they first appeared:

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)

6 thoughts on “Effective Concurrency: Use Threads Correctly = Isolation + Asynchronous Messages

  1. If the best way to use threads is Isolation + Asynchronous Messages then I would use processes talking via some type of queue (sockets, message queues, shared memory queues, whatever.)

    They naturally enforce the level of isolation and the type of communication you want, and for client-side work the additional overhead is negligible (I did not say zero, I said the user is hardly going to notice.)
    If you are on a busy server, then the story is different.

    What did I miss?

  2. I’ve brought it to their attention and resent the images. Oddly, the images always look fine in the “print” version (the print magazine while it was alive, and now the PDF print-like version they email to subscribers), but have variable quality on the website.

  3. I’m inclined to agree with Brian – the images really let the otherwise superb quality of the article down. With my poor eyesight, I can barely read the text in the image on page 1. The others aren’t much better.

    What’s going on?

  4. Interesting article, but wow, does it look unprofessional. Shame on DDJ. These images look like they’ve been through a lossy compression cycle AND they’ve been scaled as a raster image.

  5. Great article !
    Have a question: quote “Getting work off the GUI thread using a thread pool (appropriate for shorter and non-blocking work)”.

    Why there is such a strong requirement there, that it has to be non-blocking and shorter work ? (compare it to async options: Dedicated Background Thread and Background Thread Per Task)

Comments are closed.