Eine release-Operation synchronisiert sich mit einer acquire-Operation auf der gleichen atomaren Variable und erzeugt dazu noch eine Ordnungsbedingung. Damit lassen sich Threads auf performante Weise synchronisieren, wenn sie auf einer gemeinsamen atomaren Variablen agieren. Doch wie lassen sich zwei Threads mit der Acquire-Release-Semantik synchronisieren, wenn sie auf keiner gemeinsamen atomaren Variablen agieren? Eine globale Ordnung der Threads mit Hilfe der Sequenziellen Konsistenz ist oft zu schwergewichtig.

Nachdem ich in den letzten drei Artikel die Summe eines Vektors in drei verschiedenen Strategien berechnet habe, möchte ich mit diesem Artikel mein Fazit ziehen.

Zwei Strategien bin ich bisher bei meiner Addition aller Elemente eines std::vector gefolgt. Zum einen habe ich die ganze Summation in einem Thread ausgeführt (Single-Threaded: Summe der Elemente eines Vektors), zum anderen alle Threads auf einer gemeinsamen Summations-Variable (Multithreaded: Addition mit einer geteilten Variable) agieren lassen. Gerade die zweite Strategie war sehr naiv. In diesem Artikel werde ich meine Erkenntnisse aus beiden Artikeln anwenden. Mein Ziel wird es daher sein, die Threads möglichst unabhängig ihre Arbeit ausführen zu lassen und die Synchronisation der Threads auf der Summations-Variable zu minimieren.

Ziel dieses Artikels ist es, die Summe aller Elemente eines Vektors zu bilden. Habe ich es im letzten Artikel mit einem Thread versucht, nütze ich dieses mal die volle Power meiner PCs. Ich verwende eine gemeinsame Summen-Variable, die von allen Threads gleichzeitig benutzt wird. Was bei ersten Hinsehen wie eine gute Idee klingt, ist bei genauerem Blick eine sehr naive Strategie. Überwiegt der Aufwand für die Synchronisation der Summen-Variable deutlich den Performanzvorteil der vier bzw. zwei CPUs.

Wie lassen sich die Werte eines std::vector am schnellsten zusammenaddieren? Diese Frage will ich in mehreren Artikeln nachgehen. Als Referenzwert soll dabei die Addition in einem Thread dienen. In weiteren Artikel gehe ich auf atomare Variablen, Locks, Tasks und threadlokale Daten ein.

Ich hätte nie gedacht, dass ich mit meinem letzten Artikel zum Threadsicheres Initialisieren eines Singleton soviel Emotion wecken würde. Daher will ich diesen Artikel nützen, die Emotionen zusammenzufassen.

Singletons lassen sich in vielen Variationen in C++11 threadsicher initialisieren. Dabei können vereinfachend gesprochen Zusicherung der C++-Laufzeit, Locks oder auch atomare Operationen verwendet werden. Mich interessiert vor allem in diesem Artikel die Antwort auf die Frage: Welche Performanzunterschiede bestehen zwischen den Variationen?

Der erzeugende Thread muss sich um die Lebenszeit seines erzeugten Threads (th) kümmern. Der Erzeuger wartet entweder, bis sein Kind seine Arbeit vollzogen hat (th.join()) oder er trennt sich von ihm (th.detach()). Das ist alles ein alter Hut. Dies gilt aber nicht für std:.async. Der große Charme von std::async besteht auch darin, dass sich der Erzeuger nicht um die Lebenszeit seines Kindes kümmern muss. 

Mit C++14 erhielt C++ Reader-Writer Locks. Die Idee ist einfach und überzeugend. Während beliebig viele Threads gleichzeitig lesend auf einen kritischen Bereich zugreifen dürfen, darf nur genau ein Thread auf diesen schreibend zugreifen.