mutex

A Null Object encapsulates a do nothing behavior inside an object. It is often pretty comfortable to use a neutral object.

In the last post "Dining Philosophers Problem I", Andre Adrian started his analysis of the classical dining philosophers' problem. Today, he uses atomics, mutexes, and locks.

If you want to have fun with threads, you should share mutable data between them. In order to get no data race and, therefore, undefined behavior, you have to think about the synchronization of your threads.

There are a lot of issues with the singleton pattern. I'm totally aware of that. But the singleton pattern is an ideal use case for a variable, which has only to be initialized in a thread-safe way. From that point on you can use it without synchronization. So in this post, I discuss different ways to initialize a singleton in a multithreading environment. You get the performance numbers and can reason about your uses cases for the thread-safe initialization of a variable.

If the previous post showed something, it's that you should use mutexes with great care. That's why you should wrap them in a lock.

Usage of mutexes seems extremely simple. There is a critical section in the code, which can only be accessed by a single thread at any point of time. It's ensured by a mutex m. The calls m.lock() and m.unlock() guarantee this exclusivity. But, the devil is in the details.