Modern C++ on kenji.blog

Einführung in die C++ Multithreading-Programmierung und asynchrone Verarbeitung (std::async)

Sat, 12 Sep 2026 08:00:00 +0900

In der modernen Softwareentwicklung ist die Multithreading-Programmierung unerlässlich, um die Leistung von Mehrkern-CPUs optimal auszuschöpfen. C++ hat ab C++11 APIs für Multithreading und asynchrone Verarbeitung (<thread>, <mutex>, <condition_variable>, <future>) als Standardbibliothek eingeführt. Dadurch können plattformunabhängige und sichere parallele Verarbeitungen implementiert werden, ohne plattformabhängigen Code (wie POSIX-Threads oder Windows-APIs) schreiben zu müssen. Darüber hinaus wurden mit den Versions-Upgrades zu C++14, C++17 und C++20 sicherere und fortschrittlichere Funktionen wie std::scoped_lock und std::jthread hinzugefügt.

In diesem Artikel werden die Grundlagen der C++ Multithreading-Programmierung, Synchronisationsmechanismen zur Vermeidung von Datenwettläufen (Data Races) sowie moderne asynchrone Verarbeitung (std::async) und das Konzept von Thread-Pools ausführlich mit detaillierten Codebeispielen erläutert.

1. Grundlagen der parallelen Verarbeitung und das Amdahlsche Gesetz

Das Hauptziel der Nutzung von Multithreading ist die “Leistungssteigerung”, jedoch kann nicht das gesamte Programm parallelisiert werden. Hierbei ist das Amdahlsche Gesetz (Amdahl’s Law) von großer Bedeutung.

Das Amdahlsche Gesetz ist ein Modell, das vorhersagt, wie sehr sich die Gesamtleistung des Systems verbessert, wenn ein Teil des Programms parallelisiert und beschleunigt wird.

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

$S(N)$ : Theoretisch maximale Geschwindigkeitssteigerung
$P$ : Anteil des gesamten Programms, der parallelisiert werden kann (0 ≤ $P$ ≤ 1)
$N$ : Anzahl der Prozessoren (Threads)

Eine wichtige Erkenntnis aus dieser Formel ist, dass “unabhängig davon, wie sehr man die Anzahl der Prozessoren $N$ erhöht, der nicht parallelisierbare serielle Teil $(1 - P)$ zu einem Engpass wird und es eine Obergrenze für die Geschwindigkeitssteigerung gibt.” Selbst wenn beispielsweise $90\%$ des Programms parallelisierbar sind ($P = 0.9$), bleibt der restliche Teil von $10\%$ sequenziell, sodass die maximale Beschleunigung selbst mit einer unendlichen Anzahl von Prozessoren nur das $10$-fache ($S(\infty) = 1 / 0.1$) beträgt.

Daher ist bei der Multithreading-Programmierung in C++ nicht nur das Hinzufügen von Threads erforderlich, sondern ein Design, das die sequenziellen Verarbeitungsteile (wie Lock-Konflikte und Synchronisations-Overhead) so weit wie möglich reduziert.

2. Grundlagen von Threads: `std::thread` und `std::jthread` (C++20)

Der klassische `std::thread` (C++11)

Der in C++11 eingeführte std::thread ist die grundlegendste Klasse, um Funktionen oder Lambda-Ausdrücke in einem neuen Thread auszuführen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <thread>

void workerFunction(int id) {
 std::cout << "Worker " << id << " is running on thread "
 << std::this_thread::get_id() << std::endl;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // Erstellen und Starten des Threads
 std::thread t1(workerFunction, 1);

 // Erstellen eines Threads mithilfe eines Lambda-Ausdrucks
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // Warten auf das Beenden der Threads (join)
 t1.join();
 t2.join();

 std::cout << "All threads completed." << std::endl;
 return 0;
}

Ein wichtiger Punkt bei std::thread ist, dass vor der Zerstörung zwingend join() oder detach() aufgerufen werden muss. Wenn der Destruktor von std::thread aufgerufen wird, ohne dass eines von beiden ausgeführt wurde, wird std::terminate() aufgerufen und das Programm stürzt ab. Um Ausnahmesicherheit (Exception Safety) zu gewährleisten, musste man eigene Wrapper-Klassen unter Verwendung des RAII-Musters schreiben.

Der moderne `std::jthread` (C++20)

In C++20 wurde der std::jthread (joining thread) eingeführt, der diese Nachteile behebt. Der std::jthread ruft in seinem Destruktor automatisch join() auf, sodass man selbst im Falle von Ausnahmen sicher auf die Beendigung des Threads warten kann. Außerdem bietet er eine Funktion zur kooperativen Thread-Stornierung über ein std::stop_token.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <iostream>
#include <thread>
#include <chrono>

int main() {
 // C++20: std::jthread
 // Durch Empfangen eines std::stop_token als erstes Argument kann eine Stornierungsanforderung erkannt werden
 std::jthread jt([](std::stop_token stoken) {
 while (!stoken.stop_requested()) {
 std::cout << "Working..." << std::endl;
 std::this_thread::sleep_for(std::chrono::milliseconds(500));
 }
 std::cout << "Stop requested. Exiting thread." << std::endl;
 });

 std::this_thread::sleep_for(std::chrono::seconds(2));

 // Explizit eine Stornierung anfordern
 jt.request_stop();

 // Da im Destruktor des jthread automatisch join() aufgerufen wird, ist ein manuelles join() nicht erforderlich
 return 0;
}

3. Vermeidung von Datenwettläufen und Synchronisation: Mutex und Locks

Wenn mehrere Threads gleichzeitig auf denselben Speicherbereich (wie eine Variable) zugreifen und mindestens einer davon schreibt, tritt ein Datenwettlauf (Data Race) auf. Im C++-Standard führt ein Datenwettlauf zu undefiniertem Verhalten (Undefined Behavior). Um dies zu verhindern, ist eine exklusive Kontrolle (Mutual Exclusion) mithilfe von std::mutex erforderlich.

`std::mutex` und `std::lock_guard`

Das manuelle Aufrufen der rohen Methoden std::mutex::lock() und unlock() wird nicht empfohlen, da das Risiko besteht, dass bei einer Ausnahme unlock() nicht aufgerufen wird und es zu einem Deadlock kommt. In C++ verwendet man stattdessen std::lock_guard (C++11) oder std::scoped_lock (C++17), die das RAII-Muster anwenden.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <iostream>
#include <vector>
#include <thread>
#include <mutex>

std::mutex g_mutex;
int g_counter = 0;

void incrementCounter(int iterations) {
 for (int i = 0; i < iterations; ++i) {
 // Beim Verlassen des Gültigkeitsbereichs wird automatisch unlock() aufgerufen
 std::lock_guard<std::mutex> lock(g_mutex);
 ++g_counter;
 }
}

int main() {
 std::vector<std::thread> threads;
 for (int i = 0; i < 10; ++i) {
 threads.emplace_back(incrementCounter, 10000);
 }

 for (auto& t : threads) {
 t.join();
 }

 std::cout << "Final counter value: " << g_counter << std::endl;
 // Wird wie erwartet 100000 sein
 return 0;
}

`std::unique_lock`

std::lock_guard ist ein einfaches bereichsbasiertes Sperren, aber wenn eine flexiblere Kontrolle (wie verzögertes Sperren, zeitgesteuertes Sperren, vorzeitiges Entsperren usw.) erforderlich ist, verwendet man std::unique_lock. Für die im nächsten Abschnitt erklärte std::condition_variable ist ein std::unique_lock zwingend erforderlich.

4. Kommunikation zwischen Threads: `std::condition_variable`

Um Muster wie das “Erzeuger-Verbraucher-Muster (Producer-Consumer Pattern)” zu implementieren, bei dem ein Thread wartet, bis eine bestimmte Bedingung erfüllt ist, und ein anderer Thread eine Benachrichtigung sendet, wenn er diese Bedingung erfüllt hat, verwendet man std::condition_variable.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

std::mutex g_mtx;
std::condition_variable g_cv;
std::queue<int> g_dataQueue;
bool g_isFinished = false;

void producer() {
 for (int i = 1; i <= 5; ++i) {
 std::this_thread::sleep_for(std::chrono::milliseconds(200));
 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_dataQueue.push(i);
 std::cout << "Produced: " << i << std::endl;
 }
 g_cv.notify_one(); // Verbraucher benachrichtigen
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // Beendigung benachrichtigen
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // Warten, bis die Bedingung erfüllt ist (Warteschlange nicht leer oder Beendigungsflag gesetzt)
 // Einen Lambda-Ausdruck verwenden, um Fehlauslösungen (Spurious Wakeups) zu verhindern
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // Entsperren und schwere Arbeit ausführen (hier nur Ausgabe)
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // Sperre wieder erwerben
 }

 if (g_isFinished && g_dataQueue.empty()) {
 break;
 }
 }
}

int main() {
 std::thread t1(producer);
 std::thread t2(consumer);
 t1.join();
 t2.join();
 return 0;
}

In diesem Beispiel versetzt std::condition_variable::wait den Thread in einen Schlafzustand, bis die Bedingung erfüllt ist, wodurch ein unnötiger Verbrauch von CPU-Ressourcen (Busy Waiting) verhindert wird.

5. Hochgradig abstrakte asynchrone Verarbeitung: `std::future`, `std::promise`, `std::async`

Die bisher besprochenen std::thread und std::mutex sind leistungsstark, bringen jedoch lediglich die Low-Level-Thread-Mechanismen des Betriebssystems nach C++. Um Ergebnisse abzurufen oder Ausnahmen weiterzuleiten, wird der Code schnell unübersichtlich. Wenn Sie parallele Verarbeitungen mit Rückgabewerten oder asynchrone Verarbeitungen auf höherer Ebene ausführen möchten, verwenden Sie die Funktionen des <future>-Headers.

`std::promise` und `std::future`

std::promise repräsentiert die Seite, die das Ergebnis “setzt”, und std::future repräsentiert die Seite, die das Ergebnis “empfängt”. Diese fungieren als sichere Kanäle zur Übergabe von Ergebnissen oder Ausnahmen zwischen Threads.

Aufgabenbasierte parallele Verarbeitung mit `std::async`

Die empfohlene Methode zur Ausführung asynchroner Aufgaben in C++ ist die Verwendung von std::async. std::async führt Aufgaben asynchron aus und gibt ein std::future zurück, um das Ergebnis zu erhalten.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#include <iostream>
#include <future>
#include <chrono>

int complexCalculation(int x) {
 std::cout << "Calculation started on thread: "
 << std::this_thread::get_id() << std::endl;
 std::this_thread::sleep_for(std::chrono::seconds(2));
 if (x < 0) {
 throw std::invalid_argument("x must be positive");
 }
 return x * 42;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // Verwenden Sie std::launch::async, um die Ausführung in einem anderen Thread zu erzwingen
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

 std::cout << "Main thread is doing other work..." << std::endl;

 try {
 // Der Aufruf von get() blockiert den aktuellen Thread und wartet, bis die Berechnung abgeschlossen ist
 int result = resultFuture.get();
 std::cout << "Result: " << result << std::endl;
 } catch (const std::exception& e) {
 std::cerr << "Exception caught: " << e.what() << std::endl;
 }

 return 0;
}

Das Verhalten von std::async ist im folgenden Sequenzdiagramm dargestellt.

sequenceDiagram participant Main as "Hauptthread" participant Async as "std::async Worker" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "Andere Arbeit erledigen..." Main->>Async: "future.get() (Blockiert bis bereit)" Note right of Async: "Berechnungen..." Async-->>Main: "Ergebnis zurückgeben oder Ausnahme werfen" deactivate Async

Für das erste Argument von std::async, die Startrichtlinie (Launch Policy), gibt es folgende zwei Arten:

std::launch::async: Erzwingt die asynchrone Ausführung durch Erstellen eines neuen Threads (oder Zuweisung aus einem Thread-Pool).
std::launch::deferred: Verzögerte Auswertung. Die Funktion wird synchron im aufrufenden Thread ausgeführt, wenn future.get() oder future.wait() aufgerufen wird.

Wenn standardmäßig (ohne Angabe) vorgegangen wird, hängt es von der Implementierung ab und wird basierend auf der Systemlast ausgewählt. Wenn Sie sicherstellen möchten, dass die Ausführung asynchron erfolgt, geben Sie std::launch::async explizit an.

6. Das Konzept des Thread-Pools (Thread Pool)

Wenn Sie std::async jedes Mal aufrufen oder std::thread wiederholt in einer Schleife erstellen und zerstören, wird der Overhead durch Thread-Kontextwechsel und die Zuweisung von Betriebssystemressourcen unübersehbar. Insbesondere bei der Verarbeitung einer großen Menge kleiner Aufgaben (Fine-grained tasks) ist die Verwendung eines Thread-Pools unerlässlich.

Ein Thread-Pool ist eine Architektur, bei der beim Starten der Anwendung eine bestimmte Anzahl von Worker-Threads (Worker) im Voraus erstellt wird. Aufgaben werden in einer Warteschlange (Queue) gesammelt und von den freien Worker-Threads nacheinander abgearbeitet.

In der C++-Standardbibliothek (Stand C++23) gibt es keine Standardklasse für Thread-Pools. Durch die Kombination von std::thread, std::mutex, std::condition_variable, std::function und std::packaged_task kann jedoch in wenigen Zeilen Code ein effizienter Thread-Pool implementiert werden. In der Praxis ist es auch üblich, asynchrone I/O-Operationen von Boost.Asio oder Bibliotheken von Drittanbietern zu verwenden.

7. Überlegungen zu Leistung und Skalierbarkeit

Um die beste Leistung bei der Multithreading-Programmierung zu erzielen, muss nicht nur auf die Parallelisierung des Codes, sondern auch auf die Hardwarearchitektur geachtet werden.

False Sharing (Falsches Teilen): Wenn mehrere Threads verschiedene Variablen aktualisieren, diese Variablen sich jedoch in derselben Cache-Zeile (normalerweise 64 Byte) der CPU befinden, kommt es zu unnötigen Speichersynchronisationen, um die Cache-Kohärenz aufrechtzuerhalten, was zu einem drastischen Leistungsabfall führt. Um dies zu verhindern, ist es erforderlich, Variablen mithilfe des alignas-Spezifikators an den Grenzen von Cache-Zeilen auszurichten.
Lock-Free (Sperrfrei) und std::atomic: Um den Overhead des Sperrens/Entsperrens von Mutexen zu vermeiden, wird der Einsatz unteilbarer Operationen (wie Compare-And-Swap) mittels <atomic> oder sperrfreier Datenstrukturen in Betracht gezogen. Da jedoch ein korrektes Verständnis der Speicherordnung (std::memory_order) erforderlich ist und die Implementierung sehr schwierig ist, sollten diese in der Regel nur eingeführt werden, wenn sie nach sorgfältigen Leistungsmessungen als notwendig erachtet werden.

8. Fazit

Dieser Artikel behandelte Multithreading und asynchrone Programmierung in C++ von den Grundlagen bis zu den neuesten C++20-Funktionen. Die wichtigsten Punkte sind:

Verwenden Sie standardmäßig std::async: Nutzen Sie für einzelne asynchrone Aufgaben oder parallele Verarbeitungen, die ein Ergebnis zurückgeben, das sicherere std::async und std::future, anstatt Threads manuell zu verwalten.
std::jthread für die Thread-Verwaltung: Verwenden Sie für Threads, die langfristig im Hintergrund laufen, den std::jthread aus C++20, um eine sichere Beendigung zu gewährleisten.
Nutzen Sie RAII zur Synchronisation: Die Sperrung von Mutexen zur Vermeidung von Datenwettläufen sollte immer über std::lock_guard oder std::unique_lock erfolgen.
Beachten Sie den Overhead: Vermeiden Sie die übermäßige Erstellung von Threads und führen Sie bei Bedarf eine Thread-Pool-Architektur ein.

Fehler bei der parallelen Verarbeitung (Deadlocks, Datenwettläufe) sind schwer zu reproduzieren und gehören zu den am schwersten zu debuggenden Problemen. Behalten Sie immer die Thread-Sicherheit im Auge und wählen Sie geeignete Tools aus der Standardbibliothek aus, um ein robustes und schnelles System mit modernem C++ zu entwickeln.

Nutzung von Smart Pointern (std::unique_ptr / shared_ptr) zur Vermeidung von Speicherlecks

Sat, 12 Sep 2026 07:00:00 +0900

Die Speicherverwaltung in C++ war lange Zeit eine der größten Herausforderungen für Entwickler. Der traditionelle Speicherverwaltungsstil, der auf manuellem new und delete beruhte, war eine Brutstätte für schwerwiegende Fehler wie Speicherlecks (Memory Leaks), baumelnde Zeiger (Dangling Pointers) und doppelte Freigaben (Double Frees). Mit dem Aufkommen von Modern C++ (seit C++11) hat sich die Situation jedoch dramatisch verändert. Den Kern dieser Veränderung bilden die “Smart Pointer” (Intelligente Zeiger).

In diesem Artikel werden die Funktionsweise und fortgeschrittene Nutzungstechniken von std::unique_ptr, std::shared_ptr und std::weak_ptr – leistungsstarken Werkzeugen zur Beseitigung von Speicherlecks und zur Realisierung einer sicheren und effizienten Ressourcenverwaltung – äußerst detailliert erläutert. Dabei gehen wir auch auf die interne Implementierung (Kontrollblöcke und atomare Operationen), die Auswirkungen auf die Leistung sowie die Formulierung der Referenzzählung durch mathematische Modelle ein.

1. Einführung: Das dunkle Zeitalter der C++-Speicherverwaltung und die Morgendämmerung von Modern C++

In der früheren C++-Entwicklung mussten Entwickler selbst dafür sorgen, dass auf dem Heap reservierter Speicher wieder freigegeben wurde.

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... Irgendeine Verarbeitung ...
 if (some_condition) {
 return; // Speicherleck tritt auf! delete wird nicht aufgerufen
 }
 delete ptr;
}

In Code wie dem obigen wird delete übersprungen, wenn eine Ausnahme auftritt oder eine frühzeitige Rückkehr (Early Return) stattfindet, was zu einem Speicherleck führt. Das Paradigma, um dies zu verhindern, ist “RAII (Resource Acquisition Is Initialization)”. RAII ist eine Technik, die die Zuweisung von Ressourcen an die Initialisierung eines Objekts (Konstruktor) und die Freigabe von Ressourcen an die Zerstörung des Objekts (Destruktor) bindet. Smart Pointer sind ein Klassen-Stack der Standardbibliothek, der dieses RAII-Idiom auf die Speicherverwaltung anwendet.

2. `std::unique_ptr`: Exklusives Eigentum ohne Overhead (Zero-Overhead)

std::unique_ptr ist ein Smart Pointer, der “exklusives Eigentum” (Exclusive Ownership) an einem dynamisch zugewiesenen Objekt besitzt. Es kann immer nur ein einziger unique_ptr eine bestimmte Ressource besitzen.

2.1 Das Prinzip des Zero-Overhead

Der größte Reiz von std::unique_ptr ist seine Leistung. Im Standardzustand, ohne benutzerdefinierten Deleter (Custom Deleter), ist die Größe von std::unique_ptr exakt identisch mit der eines rohen Zeigers (Raw Pointer). Er besitzt keine unnötigen Elementvariablen und es werden keine virtuellen Funktionen verwendet. Durch Compiler-Optimierungen wird der Zugriff über std::unique_ptr in denselben Assembler-Code übersetzt wie der eines rohen Zeigers.

2.2 Eigentumsübertragung und `std::move`

Da er exklusives Eigentum besitzt, kann std::unique_ptr nicht kopiert werden (Kopierkonstruktor und Kopierzuweisungsoperator sind als delete markiert). Um das Eigentum auf einen anderen unique_ptr zu übertragen, wird std::move verwendet, um Move-Semantik (Move Semantics) zu nutzen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <memory>

class Resource {
public:
 Resource() { std::cout << "Resource acquired\n"; }
 ~Resource() { std::cout << "Resource destroyed\n"; }
 void do_something() { std::cout << "Doing something\n"; }
};

void process_resource(std::unique_ptr<Resource> ptr) {
 ptr->do_something();
 // Wenn der Gültigkeitsbereich (Scope) verlassen wird, wird ptr zerstört und auch Resource freigegeben
}

int main() {
 std::unique_ptr<Resource> my_ptr = std::make_unique<Resource>();

 // process_resource(my_ptr); // Fehler: Kopieren nicht möglich
 process_resource(std::move(my_ptr)); // Eigentumsübertragung

 if (!my_ptr) {
 std::cout << "my_ptr is now empty.\n";
 }
 return 0;
}

Das folgende Mermaid-Diagramm veranschaulicht das Konzept der Eigentumsübertragung durch std::move.

2.3 Implementierung eines benutzerdefinierten Deleters

Wenn man Legacy-APIs aus C (wie z. B. FILE* oder Sockets) verpackt, muss man für die Speicherfreigabe andere Funktionen als delete aufrufen (z. B. fclose). std::unique_ptr ermöglicht es, im zweiten Template-Argument einen benutzerdefinierten Deleter anzugeben.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <cstdio>
#include <memory>

// Funktor für benutzerdefinierten Deleter
struct FileDeleter {
 void operator()(FILE* fp) const {
 if (fp) {
 std::cout << "Closing file.\n";
 std::fclose(fp);
 }
 }
};

using UniqueFile = std::unique_ptr<FILE, FileDeleter>;

int main() {
 UniqueFile file(std::fopen("test.txt", "w"));
 if (file) {
 std::fputs("Hello, Smart Pointers!", file.get());
 }
 // Am Ende des Gültigkeitsbereichs wird FileDeleter aufgerufen und fclose ausgeführt
 return 0;
}

Die Verwendung von Funktionszeigern oder Lambda-Ausdrücken als benutzerdefinierte Deleter kann die Größe von unique_ptr erhöhen. Wenn man jedoch, wie oben gezeigt, zustandslose Funktionsobjekte (Funktoren) verwendet, erhöht sich die Größe durch EBCO (Empty Base Class Optimization) in C++ oder [[no_unique_address]] in C++20 nicht gegenüber einem rohen Zeiger (der Zero-Overhead bleibt erhalten).

3. `std::shared_ptr`: Gemeinsames Eigentum und Kontrollblock

std::shared_ptr ist ein Smart Pointer, der es mehreren Zeigern ermöglicht, dasselbe Objekt gemeinsam zu besitzen. Wenn der letzte shared_ptr zerstört wird, wird das verwaltete Objekt freigegeben.

3.1 Interne Architektur: Der Kontrollblock

std::shared_ptr weist neben dem Zeiger auf das verwaltete Objekt Metadaten, den sogenannten Kontrollblock (Control Block), auf dem Heap zu und teilt diese. Der Kontrollblock enthält die folgenden Informationen:

Strong Count (Starke Referenzzählung): Die Anzahl der shared_ptr, die das Objekt besitzen. Wenn diese 0 erreicht, wird das Objekt zerstört.
Weak Count (Schwache Referenzzählung): Die Anzahl der weak_ptr, die das Objekt überwachen. Wenn sowohl der Strong Count als auch der Weak Count 0 erreichen, wird der Kontrollblock selbst freigegeben.
Benutzerdefinierter Deleter und Allokator (falls angegeben).

Aus diesem Grund ist die Größe des std::shared_ptr-Objekts selbst normalerweise doppelt so groß wie ein roher Zeiger (ein Zeiger auf das Objekt und ein Zeiger auf den Kontrollblock).

3.2 Leistung und atomare Operationen

Die Referenzzählungen im Kontrollblock sind als atomare Operationen (Atomic Operations) implementiert, sodass sie auch in Multithreading-Umgebungen sicher inkrementiert und dekrementiert werden können.

Auf x86/x64-Architekturen werden für das Inkrementieren und Dekrementieren der Referenzzählung atomare Befehle wie lock xadd verwendet. Dies geht im Vergleich zur normalen Ganzzahl-Addition mit einem Overhead von mehreren Dutzend Zyklen einher. Wenn man also shared_ptr per Wertübergabe (Pass-by-Value) an eine Funktion übergibt, erfolgen bei jedem Kopiervorgang ein atomares Inkrement und Dekrement, was die Leistung beeinträchtigt.

Best Practice: Wenn man einen shared_ptr an eine Funktion übergibt, sollte man ihn entweder als const std::shared_ptr<T>& (const-Referenz) oder als rohen Zeiger/Referenz übergeben, es sei denn, man muss das Eigentum teilen.

3.3 `std::make_shared` vs `new`

Bei der Erstellung von shared_ptr sollte man nach Möglichkeit std::make_shared verwenden. Dafür gibt es zwei wesentliche Gründe:

Optimierung der Speicherzuweisung: Wenn man new verwendet, treten zwei Heap-Allokationen auf: eine für das Objekt selbst und eine für den Kontrollblock. Bei Verwendung von std::make_shared kann ein einzelner großer Speicherblock, der beides umfasst, in einer einzigen Heap-Allokation reserviert werden, was auch die Cache-Effizienz verbessert.
Ausnahmesicherheit (Exception Safety): In Standards vor C++17 war die Auswertungsreihenfolge von Funktionsargumenten nicht festgelegt. Wenn eine Ausnahme bei der Auswertung eines anderen Arguments auftrat, bevor der mit new reservierte Zeiger an den Konstruktor von shared_ptr übergeben wurde, bestand die Gefahr eines Speicherlecks. make_shared vermeidet dieses Problem vollständig.

1
2
3
4
5


// Zu vermeidende Schreibweise (2 Speicherallokationen)
std::shared_ptr<MyClass> ptr1(new MyClass());

// Empfohlene Schreibweise (1 Speicherallokation)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: Auflösung von Zirkelbezügen und Überwachung

Das gemeinsame Eigentum hat eine fatale Schwachstelle: “Zirkelbezüge” (Circular References). Wenn Objekt A und Objekt B mit shared_ptr gegenseitig aufeinander verweisen, bleibt der Strong Count für beide mindestens bei 1, wird bis zum Ende des Programms niemals 0 und es kommt zu einem Speicherleck.

graph TD subgraph "Zirkelbezug (Speicherleck)" A["Objekt A"] -->|"shared_ptr (Strong=1)"| B["Objekt B"] B -->|"shared_ptr (Strong=1)"| A end

4.1 Durchbrechen des Zirkelbezugs mit `std::weak_ptr`

Die Lösung für dieses Problem ist std::weak_ptr. Ein weak_ptr wird aus einem shared_ptr erstellt und verweist auf das Objekt, erhöht aber nicht den Strong Count. Stattdessen wird der Weak Count erhöht. Dadurch kann man das Objekt “überwachen”, ohne Eigentum daran zu besitzen.

graph TD subgraph "Durchbrechen des Zirkelbezugs" C["Objekt A"] -->|"shared_ptr (Strong=1)"| D["Objekt B"] D -.->|"weak_ptr (Weak=1)"| C end

4.2 Sicherer Zugriff über die `lock()`-Methode

weak_ptr hat keine Operatoren für den direkten Zugriff auf das Objekt (-> oder *). Der Grund dafür ist, dass das Zielobjekt möglicherweise bereits zerstört wurde. Um sicher darauf zuzugreifen, ruft man die Methode lock() auf, um temporär einen shared_ptr zu erhalten.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#include <memory>

class Node {
public:
 std::string name;
 std::shared_ptr<Node> next;
 std::weak_ptr<Node> prev; // weak_ptr verwenden, um Zirkelbezüge zu vermeiden

 Node(const std::string& n) : name(n) { std::cout << "Created " << name << "\n"; }
 ~Node() { std::cout << "Destroyed " << name << "\n"; }
};

int main() {
 auto nodeA = std::make_shared<Node>("A");
 auto nodeB = std::make_shared<Node>("B");

 nodeA->next = nodeB;
 nodeB->prev = nodeA;

 // shared_ptr von weak_ptr abrufen und zugreifen
 if (auto locked_prev = nodeB->prev.lock()) {
 std::cout << "Node B's prev is " << locked_prev->name << "\n";
 } else {
 std::cout << "Node B's prev is already destroyed.\n";
 }

 return 0; // nodeA und nodeB werden ordnungsgemäß zerstört
}

5. Einschränkungen des gemeinsamen Eigentums in Multithreading-Umgebungen

Die Threadsicherheit von shared_ptr wird oft missverstanden. Zwar gilt: “Die Aktualisierung der Referenzzählung im Kontrollblock ist threadsicher”, aber “Das Lesen und Schreiben des shared_ptr-Objekts selbst ist nicht threadsicher”.

Sichere Operationen: Mehrere Threads lesen und schreiben jeweils ihre eigenen shared_ptr-Instanzen (die jedoch denselben Kontrollblock teilen).
Data Race (Gefährlich): Mehrere Threads lesen und schreiben gleichzeitig in genau dieselbe shared_ptr-Instanz.

Wenn dieselbe Instanz von mehreren Threads gemeinsam genutzt werden muss, muss std::atomic<std::shared_ptr<T>> (C++20) verwendet werden oder sie muss durch einen Mutex (std::mutex) geschützt werden.

6. Mathematische Formulierung der Referenzzählung

Die Zustandsübergänge des Lebenszyklus im Kontrollblock lassen sich mathematisch wie folgt ausdrücken. Sei $S(t)$ der Strong Count und $W(t)$ der Weak Count zum Zeitpunkt $t$.

Anfangszustand (unmittelbar nach make_shared):

$$ S(0) = 1, \quad W(0) = 0 $$

Wenn eine Kopie (Duplikation von shared_ptr) erfolgt:

$$ S(t_{next}) = S(t) + 1 $$

Bedingung, unter der das verwaltete Objekt (Managed Object) zerstört wird:

$$ \lim_{t \to t_d} S(t) = 0 $$

Bedingung, unter der der Kontrollblock (Control Block) selbst aus dem Speicher freigegeben wird:

$$ S(t) = 0 \quad \land \quad W(t) = 0 $$

Das heißt:

$$ S(t) + W(t) = 0 $$

Wie diese Formeln zeigen, bleibt der kleine Speicherplatz für den Kontrollblock weiterhin reserviert, solange weak_ptr existieren ($W(t) > 0$), auch wenn das verwaltete Objekt bereits zerstört wurde. Dies kann in manchen Fällen der einzige Nachteil von make_shared sein (da der Speicher des verwalteten Objekts und der Kontrollblock integriert sind, wird auch der riesige Speicherplatz für das verwaltete Objekt nicht an das System zurückgegeben, solange schwache Referenzen verbleiben). In der Regel überwiegen jedoch die Leistungsvorteile von make_shared bei Weitem.

7. Fazit

Bei der Speicherverwaltung in Modern C++ ist das manuelle Verwalten von new/delete nicht mehr zeitgemäß.

Standardmäßig sollte immer std::unique_ptr verwendet werden, um von Zero-Overhead zu profitieren und klares Eigentum in das Design zu integrieren.
std::shared_ptr sollte nur dann verwendet werden, wenn der Lebenszyklus wirklich zwischen mehreren Eigentümern geteilt werden muss. Für die Erstellung sollte std::make_shared verwendet werden.
Bei der Implementierung von Datenstrukturen, in denen gemeinsame Kreise (Zirkelbezüge) auftreten können, oder bei Observer-Mustern sollte std::weak_ptr eingesetzt werden, um Speicherlecks proaktiv zu verhindern.

Ein tiefes Verständnis von Smart Pointern und deren gezielter Einsatz an den richtigen Stellen ermöglicht den Aufbau einer sicheren und robusten Softwarearchitektur, ohne die Leistung von C++ auch nur im Geringsten zu opfern.

Modern C++ on kenji.blog

Einführung in die C++ Multithreading-Programmierung und asynchrone Verarbeitung (std::async)

1. Grundlagen der parallelen Verarbeitung und das Amdahlsche Gesetz

2. Grundlagen von Threads: std::thread und std::jthread (C++20)

Der klassische std::thread (C++11)

Der moderne std::jthread (C++20)

3. Vermeidung von Datenwettläufen und Synchronisation: Mutex und Locks

std::mutex und std::lock_guard

std::unique_lock

4. Kommunikation zwischen Threads: std::condition_variable

5. Hochgradig abstrakte asynchrone Verarbeitung: std::future, std::promise, std::async

std::promise und std::future

Aufgabenbasierte parallele Verarbeitung mit std::async