Is thread time spent in synchronization too high?

Question

Today I profiled one of my C# applications using the Visual Studio 2010 Performance Analyzer. Specifically, I was profiling for \"Concurrency\" because it s

Answer 1

There are a few ways that thread synchronization can kill performance:

1. The instructions for implementing synchronization take time to execute, especially for synchronization routines that require a transition to kernel mode such as Thread.Sleep(). In the worst case, a lone thread making frequent calls to synchronization routines introduces a whole lot of overhead for no real benefit.
2. Whenever more than one thread needs exclusive access to a resource at the same time, at least one thread gets stuck waiting. The worst case scenario here is that there is some central resource which everyone needs to access frequently. In this case, multithreaded code is in serious danger of becoming an expensive, slow, and complicated way to have one thread working at a time.

As for how much is too much: Synchronization is something that takes time but doesn't really do any useful work. Therefore, from a performance perspective the ideal amount of synchronization is always zero. Hence the high value that is placed on shared-nothing architectures and immutable data structures. Both are techniques to help organize code in a way that eliminates or reduces the need for synchronization.

Of course the world isn't ideal so some amount of synchronization is usually inescapable. But even then it should be done using the lightest-weight constructs possible. For example, don't use a lock statement when a method in Interlocked will do. Or reduce the frequency with which it needs to happen by designing threads to send work product to a central data structure in batches, rather than making a lot of high-frequency updates.