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, condition variables as future have an understanding of 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.

A 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 the two components clock and time duration.

A blog, dealing with multithreading in modern C++ but not writing about the new time library is not complete. 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 in 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 it that the thread will perform their summation as independent from each other as possible and therefore reduce the synchronization overhead. 

My goal is, to sum up, all elements of a vector. I used in the last post a single thread. In this post, I use multiple threads and therefore the full power of my PC. The addition will be done on a shared variable. What at first glance seems like a good idea is a very naive strategy. The synchronization overhead of the summation variable is higher than the performance benefit of my four or two cores.