What to avoid for performance reasons in multithreaded code?

Question

I\'m currently reviewing/refactoring a multithreaded application which is supposed to be multithreaded in order to be able to use all the available cores and theoretically deliv

Answer 1

Something to keep in mind when locking: lock for as short a time as possible. For example, instead of this:

lock(syncObject)
{
    bool value = askSomeSharedResourceForSomeValue();
    if (value)
        DoSomethingIfTrue();
    else
        DoSomtehingIfFalse();
}

Do this (if possible):

bool value = false;  

lock(syncObject)
{
    value = askSomeSharedResourceForSomeValue();
}  

if (value)
   DoSomethingIfTrue();
else
   DoSomtehingIfFalse();

Of course, this example only works if DoSomethingIfTrue() and DoSomethingIfFalse() don't require synchronization, but it illustrates this point: locking for as short a time as possible, while maybe not always improving your performance, will improve the safety of your code in that it reduces surface area for synchronization problems.

And in certain cases, it will improve performance. Staying locked for long lengths of time means that other threads waiting for access to some resource are going to be waiting longer.

Answer 2

What kills performance is when two or more threads share the same resources. This could be an object that both use, or a file that both use, a network both use or a processor that both use. You cannot avoid these dependencies on shared resources but if possible, try to avoid sharing resources.

Answer 3

You should first get a tool to monitor threads specific to your language, framework and IDE. Your own logger might do fine too (Resume Time, Sleep Time + Duration). From there you can check for bad performing threads that don't execute much or are waiting too long for something to happen, you might want to make the event they are waiting for to occur as early as possible.

As you want to use both cores you should check the usage of the cores with a tool that can graph the processor usage on both cores for your application only, or just make sure your computer is as idle as possible.

Besides that you should profile your application just to make sure that the things performed within the threads are efficient, but watch out for premature optimization. No sense to optimize your multiprocessing if the threads themselves are performing bad.

Looking for a lock-free strategy can help a lot, but it is not always possible to get your application to perform in a lock-free way.

Answer 4

One thing to definitely avoid is lots of write access to the same cache lines from threads.

For example: If you use a counter variable to count the number of items processed by all threads, this will really hurt performance because the CPU cache lines have to synchronize whenever the other CPU writes to the variable.

Answer 5

I'm using Delphi 7

You might be using COM objects, then, explicitly or implicitly; if you are, COM objects have their own complications and restrictions on threading: Processes, Threads, and Apartments.

Answer 6

You should first be familiar with Amdahl's law.

If you are using Java, I recommend the book Java Concurrency in Practice; however, most of its help is specific to the Java language (Java 5 or later).

In general, reducing the amount of shared memory increases the amount of parallelism possible, and for performance that should be a major consideration.

Threading with GUI's is another thing to be aware of, but it looks like it is not relevant for this particular problem.