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.

At Christmas time, I had a few nice discussions with Andre Adrian. He solved the classical dining philosopher's problem in various ways using modern C++. I'm convinced him to write an article about this classic synchronization issue, and I'm happy to publish it in three consecutive posts.

The new time library is an important component of the threading interface. As well, threads, locks, and condition variables understanding time. All four have in common that they can sleep, wait or block until a time point or for a time duration.

A clock consists of a starting point and a time tick. C++ offers with std::chrono::system_clock, std::chrono::steady_clock, and std::chrono::high_resolution_clock three clocks.

Time duration is the difference between two time points. It will be measured in time ticks.

The time point is defined by the starting point (epoch) and the additional time duration. It consists of two components, clock and time duration.

A blog dealing with multithreading in modern C++ but not writing about the new time library is incomplete. Especially because I often used the time library in my posts to measure the performance of shortcode snippets. Therefore, I give in this post an overview of the components of the time library: time point, time duration, and clock. I will write additional posts about each of these three components.

After I've calculated in three different ways the sum of a std::vector I want to draw my conclusions.

Until now, I've used two strategies for the summation of a std::vector. First, I did the whole math in one thread (Single Threaded: Summation of a vector); second multiple threads shared the same variable for the result (Multithreaded: Summation of a vector). In particular, the second strategy was extremely naive. In this post, I will apply my knowledge of both posts. My goal is that the thread will perform their summation as independently from each other as possible and therefore reduce the synchronization overhead.