Rainer Grimm erläutert in seiner Folge vom 6. Juli 2018 vier Empfehlungen der C++ Core Guidelines zur Lock-free-Programmierung. Im Mittelpunkt stehen CP.101, CP.102, CP.110 und CP.111. Der Beitrag erklärt bestehende Regeln; er kündigt keine neue C++-Version an.
CP.101 fordert besondere Vorsicht bei der Kombination aus Hardware und Compiler. Die damalige Fassung der Guidelines verlangt erneute Tests, wenn Hardware, Betriebssystem, Compiler oder Bibliotheken wechseln. Leistungsoptimierungen dürfen dabei nicht nur auf einer einzigen Zielkonfiguration geprüft werden. Gerade schwächere Speicherordnungen erschweren die Beurteilung der Abläufe zwischen Threads.
CP.102 verweist auf Fachliteratur zu Nebenläufigkeit und Speichermodellen. Ein mutexfreier Algorithmus ist nicht allein deshalb korrekt oder schneller. Grimm nennt deshalb zwei Vorbedingungen: Das Verfahren muss den tatsächlichen Leistungsengpass lösen, und die beteiligten Entwickler müssen es ausreichend verstehen.
Initialisierung nicht mit einem eigenen Zeigertrick absichern
CP.110 rät von selbst gebautem Double-checked Locking für die Initialisierung ab. Die Guidelines nennen stattdessen lokale statische Variablen mit der threadsicheren Initialisierung seit C++11 oder std::call_once. Eine zusätzliche Zeigerprüfung ersetzt keine korrekte Synchronisierung.
CP.111 verlangt für verbleibende Einsatzfälle ein bewährtes Muster. Die Regel ist keine allgemeine Freigabe für eigene Singleton-Konstruktionen. Der damalige Text unterscheidet ausdrücklich zwischen einmaliger Initialisierung und anderen seltenen, teuren Aktionen.
Die Empfehlungen ergänzen die Prüfung von Bedingungsvariablen. Für C++-Code in Engines und Entwicklungswerkzeugen betrifft beides denselben praktischen Punkt: Der Zugriff auf gemeinsam genutzte Zustände muss korrekt bleiben, auch wenn das Timing oder die Zielplattform wechselt.