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

Concurrency 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.

Published

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

  1. 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

  2. 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.

Comments are closed.

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s