Effective Concurrency: Avoid Calling Unknown Code While Inside a Critical Section

Herb Sutter Concurrency 2007-11-06 1 Minute

The latest Effective Concurrency column, "Avoid Calling Unknown Code While Inside a Critical Section", just went live on DDJ’s site, and will also appear in the print magazine. Here’s a teaser from the article’s intro:

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: …

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

Published by Herb Sutter

Herb Sutter is an author and speaker, a software architect at Microsoft, and chair of the ISO C++ standards committee. View all posts by Herb Sutter

Published 2007-11-06

2 thoughts on “Effective Concurrency: Avoid Calling Unknown Code While Inside a Critical Section”

(no name) says:

2008-01-14 at 2:59 am

Hi Mr Herb,

    I have read the article in dr dobbs. I would like to give one another problem if we call a method with lock from a critical section. Suppose we have the following code.

Processor::ProcessAcquiredData()

{

while(m_bisdatareadprocessingstoped)

{

Lock();

    int* p = buf.read();

    //do processing with p

    Unlock();

}

}

int* Buff::read()

{

    WaitforSingleObject(DataEvent);

    return GetdataPointer();

}

Processor::StopProcessing()

{

    m_bisdatareadprocessingstoped = false;

    WaitforSingleObject(m_handletoprocessacquiredthread);

    // Do necessary state change

}

Now suppose if i want to stop the thread one becase user want an immediate process stoping.

If we write this the program will get locked up. The locking up will occur if the data prcessing is stopped and if the waiting is inside Buff::read(). In such a case it becomes impossible to give a grace exit to thread. I think this is also an addition not to bring out any kind of wait inside another wait.
Daniel Roberts says:

2009-07-02 at 12:52 pm

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