Werden Daten während ihrer ganze Lebenszeit nur lesend von mehreren Threads verwendet, müssen diese nur sicher initialisiert werden. Das teure Locken der Daten ist bei keinem Zugriff notwendig.

Wenn der letzte Artikel Gefahren von Mutexen etwas gezeigt hat, dann, dass Mutexe mit großer Vorsicht zu genießen sind. Daher sollen Mutexe in C++ in Locks verpackt werden.

Der Einsatz von Mutexen hört sich sehr einfach an. Es gibt einen kritischen Bereich "Critical Section" im Code, den nun ein Thread betreten darf. Genau diese Exklusivität sichert ein Mutex m durch die zwei Aufrufe m.lock() und m.unlock() zu. Der Teufel steckt aber sprichwörtlich im Detail.

Die große Herausforderung mit Threads beginnt dann, wenn sich diese Daten teilen und diese nicht konstant sind.

Ein Thread kann seine Daten per Copy oder per Referenz erhalten. Per Default sollte der Thread seine Daten per Copy annehmen, da per Referenz angenommene Daten leicht ihre Gültigkeit verlieren.

Der Erzeuger muss sich um sein Kind kümmern. Diese einfache Aussage besitzt für Threads weitreichende Konsequenzen. Das kleine Programm startet einen Thread, der seine ID auf der Konsole ausgeben soll. 

Der Umgang mit Threads in C++ ist schnell erzählt. Durch den Aufruf std::thread wird ein neuer Thread erzeugt. Dieser Thread benötigt ein Arbeitspaket und startet sofort. Der erzeugende Thread (Der Erzeuger) muss sich um die Lebenszeit seines erzeugten Threads (Das Kind) kümmern. Der Erzeuger wartet entweder, bis sein Kind seine Arbeit vollzogen hat oder er trennt sich von ihm. Die Daten nimmt das Kind per Copy oder Referenz an. 

Für das Linux-Magazin schreibe ich seit 2011 eine Serie zu modernem C++, die jeden zweiten Monat erscheint. Mir war lange selbst nicht bewusst, dass das Linux-Magazin alle Artikel, die mindestens zehn Monate alt sind, online veröffentlicht.