What are common concurrency pitfalls? [closed]

Answer 1

The #1 pitfall I have seen is too much data sharing.

I believe that one of the better ways to handle concurrency is multiple processes instead of threads. In this way, communication between threads/processes is strictly limited to the chosen pipe, message queue or other communication method.

Answer 2

Calling public classes from within a lock causing a DeadLock

public class ThreadedClass
{
    private object syncHandle = new object();

    public event EventHandler Updated = delegate { };
    public int state = 0;

    public void DoSmething()
    {
        lock(syncHandle)
        {
            // some locked code
            state = 1;

            Updated(this, EventArgs.Empty);
        }
    }

    public int State { 
        get
        {
            int returnVal;
            lock(syncHandle)
                returnVal = state;
            return returnVal;            
        }
    }
}

You can't be certain what your client is going to call, Most likely they'll try to read the State property. Do this instead

public void DoSmething()
{
    lock(syncHandle)
    {
        // some locked code
        state = 1;
    }
    // this should be outside the lock
    Updated(this, EventArgs.Empty);
}

Answer 3

Concurrency doesn't have many pitfalls.

Synchronizing access to shared data, however, is tricky.

Here are some questions anyone writing shared-data synchronization code should be able to answer:

1. What is InterlockedIncrement?
2. Why does InterlockedIncrement need to exist at an assembly language level?
3. What is read write reordering?
4. What is the volatile keyword (in c++) and when do you need to use it?
5. What is a synchronization hierarchy?
6. What is the ABA problem?
7. What is cache coherency?
8. What is a memory barrier?

"Shared everything" concurrency is an extremely leaky abstraction. Adopt shared nothing message passing instead.

Answer 4

There are lots of good answers and pointers on this thread already, but let me add one thing.

DO NOT RELY ON TESTING TO FIND RACE CONDITIONS AND DEADLOCKS

Assuming you have all the good development processes in place: unit tests for each component, smoke tests for each nightly build, requiring each developer's changes to pass tests before checkin , etc.

All that is well and good, but it leads to an attitude of "well, it passed the test suite, so it can't be a bug in my code." which will not serve you well in concurrent programming. Real-time concurrency bugs are fiendishly hard to reproduce. You can run a piece of code with a race condition a billion times before it fails.

You will have to adjust your process to put greater emphasis on code reviews, conducted by your best minds. Having a seperate code review just for concurrency issues only is not a bad idea.

You will have to put more emphasis on making your application self-debugging. That is, when you get a failure in the test lab or at your customer's site, you need to make sure enough information is captured and logged to let you do a definitive postmortem, since the odds of your being able to reproduce the bug report at your convenience are negligible.

You will have to put more emphasis on paranoid sanity checks in your code so that a fault is detected as close to the problem as possible, and not 50,000 lines of code away.

Be paranoid. very paranoid.

Answer 5

Also you could look at out-of-process type concurrency problems
For instance:
A writer process making a file and a consumer process claiming the file.

Answer 6

Composability. In any non-trivial system, ad-hoc approaches to synchronisation within different sub-systems make interaction between them usually error-prone and occasionally impossible. See this video for an example of how even the most trivial code is prone to these problems.

Personally, I am a convert to the Actor model of concurrent computation (the asynchronous variety).