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. 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 aware of that. But the singleton pattern is an ideal use case for a variable, which can only 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 use 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.

The usage of mutexes seems extremely simple. There is a critical section in the code that a single thread can only access at any point in 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.