Until now, I’ve used two strategies to summate 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 […]
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 […]
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 […]
With the relaxed semantics, we have no synchronizations and ordering constraints on atomic operations.
But we can improve and further improve the acquire-release semantics of the last post. Why should x be atomic? There is no reason. That was my first but incorrect assumption. See why?
With the acquire-release semantics, we break the sequential consistency. In the acquire-release semantics, synchronization occurs between atomic operations on the same atomic and not between threads.
With atomic data types, you can tailor your program to your needs and optimize it. But now we are in the domain of multithreading experts.
The easiest way to solve the undefined behaviour in the post Ongoing Optimization: Unsynchronized access is, to use a lock.
Something completely different. I’m looking for English proofreaders for my new book.