lock

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

This post ends the mini-series about the dining philosophers problem by Andre Adrian. Today, he applies powerful locks and semaphores.

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.

C++11 is the first C++ standard that deals with concurrency. The basic building block for concurrency is a thread; therefore, most rules are explicitly about threads. This changed dramatically with C++17.

What is the fastest way to add the elements of a std::vector? This a question that I will pursue in the following posts. I use the single-threaded addition as the reference number. In further posts, I discuss atomics, locks, and thread-local data.

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.

The easiest way to solve the undefined behaviour in the post Ongoing Optimization: Unsynchronized access is, to use a lock.

With C++14 came reader-writer locks. The idea is straightforward and promising. Arbitrary reading threads can access the critical region simultaneously, but only one thread is allowed to write.

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.