Best practices: syncing between threads

Question

Is if almost always required to have thread syncing (i.e. use of mutex, semaphores, critical sections, etc.) when there is cross-thread data accessing, even if it's not required after going through a requirements analysis?

Answer 1

I would always recommended going with the simplest, most straightforward synchronization scheme until analysis shows you should do otherwise - this usually means a few large locks versus many fine-grained locks or lockfree.

The issue is that determining if lock-free code is correct is much more difficult than determining if the corresponding code with locks is correct. This creates a large burden on maintainers of your code, and there is a good chance they will get it wrong and introduce bugs. Even if you know that lock-free is safe with how your code is currently used, this could change in the future by people who aren't as aware.

Secondly, in many cases, the difference in performance between code with locks and lock-free code is neglible - until you know there is an issue with lock contention, you should not consider lock-free. Even if there are contention problems, lock-free is not necessarily the best solution.

Answer 2

Even if you don't need a mutex, semaphore, critical section, etc. for their normal locking semantics, you may still need a memory barrier. The former constructs usually imply a memory barrier, which is why removing them can change the program. In addition, these problems can be extremely hard to debug, as a different scheduling of the involved threads can make the problem vanish and appear. In the simplest case, this means the mere act of running a completely separate program changes the behavior of yours.

Answer 3

The other model that makes sense is called share-nothing. erlang and scala are probably the chief representatives of this model with erlang processes and scala actors.

The idea is that you send messages to other threads, where messages are data that no reference of is kept by the sender. In practice there is a small amount of locking needed for the send/receive queues, but the rest of the code can be lock free w/o any concerns.

Such models can be implemented in C++ and other languages.

http://www.scala-lang.org/node/242 http://lambda-the-ultimate.org/node/1742 http://docs.python.org/library/multiprocessing.html#module-multiprocessing