Modern C++ on kenji.blog

Введение в многопоточное программирование и асинхронную обработку на C++ (std::async)

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

В современной разработке программного обеспечения многопоточное программирование необходимо для максимального использования производительности многоядерных процессоров. Начиная со стандарта C++11, C++ ввел API для многопоточности и асинхронной обработки (<thread>, <mutex>, <condition_variable>, <future>) в стандартную библиотеку, что позволяет реализовывать переносимую и безопасную параллельную обработку без написания платформозависимого кода (например, POSIX-потоков или Windows API). Более того, с каждой новой версией (C++14, C++17, C++20) добавлялись более безопасные и продвинутые функции, такие как std::scoped_lock и std::jthread.

В этой статье мы подробно рассмотрим основы многопоточного программирования на C++, механизмы синхронизации для предотвращения состояний гонки (data race), а также концепции современной асинхронной обработки (std::async) и пула потоков с детальными примерами кода.

1. Основы параллельной обработки и закон Амдала

Главная цель многопоточности — это «повышение производительности», однако распараллелить программу целиком невозможно. Здесь важным становится закон Амдала (Amdahl’s Law).

Закон Амдала — это модель для прогнозирования того, насколько повысится общая производительность системы, если часть программы будет распараллелена и ускорена.

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

$S(N)$ : теоретический максимальный коэффициент ускорения
$P$ : доля программы, поддающаяся распараллеливанию (0 ≤ $P$ ≤ 1)
$N$ : количество процессоров (потоков)

Важный факт, который показывает эта формула, заключается в следующем: «сколь бы сильно мы ни увеличивали количество процессоров $N$, последовательная часть $(1 - P)$, которую нельзя распараллелить, становится узким местом, и у ускорения есть предел». Например, даже если $90\%$ программы можно распараллелить ($P = 0.9$), пока оставшиеся $10\%$ обрабатываются последовательно, даже при использовании бесконечного числа процессоров максимальное ускорение составит всего $10$ раз ($S(\infty) = 1 / 0.1$).

Следовательно, при написании многопоточного кода на C++ требуется не просто увеличивать количество потоков, а создавать архитектуру, которая максимально уменьшает долю последовательной обработки (например, конкуренцию за блокировки и накладные расходы на синхронизацию).

2. Основы потоков: `std::thread` и `std::jthread` (C++20)

Традиционный `std::thread` (C++11)

Класс std::thread, представленный в C++11, является самым базовым классом для выполнения функций или лямбда-выражений в новом потоке.

 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;

 // スレッドの生成と実行開始
 std::thread t1(workerFunction, 1);

 // ラムダ式を用いたスレッドの生成
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // スレッドの終了を待機（join）
 t1.join();
 t2.join();

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

Важное замечание при использовании std::thread заключается в том, что перед уничтожением объекта необходимо обязательно вызвать join() или detach(). Если ни один из этих методов не будет вызван до срабатывания деструктора std::thread, будет вызвана функция std::terminate(), что приведет к сбою программы. Для обеспечения безопасности при исключениях (exception safety) приходилось создавать собственные классы-обертки с использованием паттерна RAII.

Современный `std::jthread` (C++20)

В C++20 для устранения этих недостатков был введен std::jthread (joining thread). Поскольку std::jthread автоматически вызывает join() в своем деструкторе, он позволяет безопасно дожидаться завершения потока даже в случае возникновения исключений. Кроме того, он имеет функцию кооперативной отмены потока с помощью 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
 // 第一引数に std::stop_token を受け取ることでキャンセル要求を検知可能
 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));

 // 明示的にキャンセルを要求
 jt.request_stop();

 // jthreadのデストラクタで自動的にjoinされるため、手動の join() は不要
 return 0;
}

3. Предотвращение состояний гонки и синхронизация: мьютексы и блокировки

Когда несколько потоков одновременно обращаются к одной и той же области памяти (например, к переменной) и хотя бы один из них выполняет запись, возникает состояние гонки (Data Race). В стандарте C++ состояние гонки приводит к неопределенному поведению (Undefined Behavior). Для предотвращения этого необходимо использовать взаимное исключение с помощью std::mutex.

`std::mutex` и `std::lock_guard`

Вызывать напрямую методы std::mutex::lock() и unlock() вручную не рекомендуется из-за риска того, что при возникновении исключения метод unlock() не будет вызван, что приведет к взаимной блокировке (deadlock). В C++ для этого используют std::lock_guard (C++11) или std::scoped_lock (C++17), которые реализуют паттерн RAII.

 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) {
 // スコープを抜けるときに自動で unlock される
 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;
 // 期待通り 100000 になる
 return 0;
}

`std::unique_lock`

В то время как std::lock_guard представляет собой простую блокировку на основе области видимости, std::unique_lock используется, когда требуется более гибкое управление (отложенная блокировка, блокировка с ограничением по времени, ранняя разблокировка и т. д.). Для std::condition_variable, который мы рассмотрим далее, использование std::unique_lock является обязательным.

4. Взаимодействие между потоками: `std::condition_variable`

Для реализации таких паттернов, как «Паттерн Производитель-Потребитель (Producer-Consumer Pattern)», где один поток ждет выполнения определенного условия, а другой отправляет уведомление, когда это условие выполняется, применяется 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(); // コンシューマに通知
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // 終了を通知
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // 条件が満たされる（キューが空でない、または終了フラグが立つ）まで待機
 // 偽起因 (Spurious Wakeup) を防ぐためラムダ式で条件を指定
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // アンロックして重い処理（ここでは出力のみ）を行う
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // 再びロックを取得
 }

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

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

В этом примере std::condition_variable::wait переводит поток в спящий режим до выполнения условия, предотвращая тем самым излишнее потребление ресурсов CPU (активное ожидание, busy loop).

5. Высокоуровневая асинхронная обработка: `std::future`, `std::promise`, `std::async`

Рассмотренные до сих пор std::thread и std::mutex мощные, однако они представляют собой низкоуровневые механизмы потоков ОС, перенесенные в C++, и код может стать громоздким при работе с получением результатов или передачей исключений. Если вам требуется параллельная обработка, возвращающая значение, или более высокоуровневая асинхронная обработка, следует использовать функции из заголовка <future>.

`std::promise` и `std::future`

std::promise представляет сторону, которая «устанавливает» результат, а std::future — сторону, которая его «получает». Они функционируют как безопасный канал передачи результатов и исключений между потоками.

Параллельная обработка на основе задач с помощью `std::async`

Наиболее рекомендуемый способ выполнения асинхронных задач в C++ — это использование std::async. std::async выполняет задачу асинхронно и возвращает объект std::future, используемый для получения результата.

 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;

 // std::launch::async を指定して強制的に別スレッドで実行
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

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

 try {
 // get() を呼ぶと、計算が終わるまで現在のスレッドをブロックして待機する
 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;
}

Поведение std::async проиллюстрировано на следующей диаграмме последовательности.

sequenceDiagram participant Main as "Главный поток" participant Async as "Рабочий поток std::async" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "Выполнение другой работы..." Main->>Async: "future.get() (Блокирует до готовности)" Note right of Async: "Вычисления..." Async-->>Main: "Возврат результата или исключение" deactivate Async

Политика запуска (Launch Policy), передаваемая в качестве первого аргумента в std::async, имеет два вида:

std::launch::async: Обязательно создает новый поток (или выделяет из пула потоков) и выполняет задачу асинхронно.
std::launch::deferred: Ленивые вычисления. Задача выполняется синхронно в вызывающем потоке в момент вызова future.get() или future.wait().

По умолчанию (если не указано) выбор зависит от реализации и может зависеть от текущей нагрузки на систему. Если вы хотите гарантированно выполнить задачу асинхронно, необходимо явно указать std::launch::async.

6. Концепция пула потоков (Thread Pool)

Если вызывать std::async каждый раз или постоянно создавать и уничтожать std::thread внутри цикла, накладные расходы на переключение контекста потоков и выделение ресурсов ОС станут значительными. Особенно при обработке большого количества мелких задач (Fine-grained tasks) использование пула потоков (Thread Pool) становится необходимым.

Пул потоков — это архитектура, при которой заданное количество рабочих потоков (Worker threads) создается заранее при запуске приложения, задачи помещаются в очередь (Queue) и последовательно обрабатываются свободными рабочими потоками.

В стандартной библиотеке C++ (на момент C++23) отсутствует стандартный класс пула потоков, однако, комбинируя std::thread, std::mutex, std::condition_variable, std::function и std::packaged_task, можно реализовать эффективный пул потоков всего в несколько десятков строк кода. В реальных проектах также распространено использование асинхронного ввода-вывода из Boost.Asio или сторонних библиотек.

7. Размышления о производительности и масштабируемости

Чтобы добиться максимальной производительности в многопоточном программировании, необходимо уделять внимание не только распараллеливанию кода, но и архитектуре оборудования.

Ложное разделение (False Sharing): Если несколько потоков обновляют разные переменные, но эти переменные расположены в одной и той же строке кэша процессора (обычно 64 байта), возникает лишняя синхронизация памяти для поддержания когерентности кэша, что резко снижает производительность. Чтобы этого избежать, необходимо использовать спецификатор alignas для выравнивания переменных по границам строк кэша.
Неблокирующие алгоритмы (Lock-Free) и std::atomic: Чтобы избежать накладных расходов на блокировку и разблокировку мьютексов, можно рассмотреть использование атомарных операций (таких как Compare-And-Swap) с помощью <atomic> и неблокирующих структур данных. Однако это требует правильного понимания порядка памяти (std::memory_order) и отличается высокой сложностью реализации, поэтому обычно внедряется только после тщательного измерения производительности и подтверждения необходимости.

8. Заключение

Мы рассмотрели многопоточное и асинхронное программирование на C++ от самых основ до новейших возможностей C++20. Основные моменты:

По умолчанию используйте std::async: Для разовых асинхронных задач или параллельных вычислений, возвращающих результат, используйте безопасные std::async и std::future вместо ручного управления потоками.
Используйте std::jthread для управления потоками: Для потоков, долго работающих в фоновом режиме, применяйте std::jthread из C++20, чтобы гарантировать безопасное завершение.
Используйте RAII для синхронизации: Блокировка мьютексов для предотвращения состояния гонки всегда должна выполняться через std::lock_guard или std::unique_lock.
Учитывайте накладные расходы: Избегайте чрезмерного создания потоков и при необходимости внедряйте архитектуру пула потоков.

Ошибки параллельного программирования (взаимные блокировки, состояния гонки) имеют низкую воспроизводимость и относятся к категории трудно поддающихся отладке. Постоянно помните о потокобезопасности и выбирайте подходящие инструменты из стандартной библиотеки для создания надежных и быстрых систем с использованием современного C++.

Использование умных указателей (std::unique_ptr / shared_ptr) для предотвращения утечек памяти

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

Управление памятью в C++ на протяжении многих лет было одной из главных проблем для разработчиков. Традиционный стиль управления памятью, опирающийся на ручное использование new и delete, служил рассадником серьезных ошибок, таких как утечки памяти, висячие указатели (dangling pointers) и двойное освобождение (double free). Однако с появлением Modern C++ (начиная с C++11) ситуация кардинально изменилась. Ядром этих изменений стали «умные указатели» (Smart Pointers).

В этой статье мы подробно рассмотрим механизмы и продвинутые методы использования std::unique_ptr, std::shared_ptr и std::weak_ptr — мощных инструментов для полного искоренения утечек памяти и реализации безопасного и эффективного управления ресурсами. Мы затронем их внутреннее устройство (управляющие блоки и атомарные операции), влияние на производительность, а также математическую модель подсчета ссылок.

1. Введение: Темные века управления памятью в C++ и рассвет Modern C++

В прошлом при разработке на C++ память, выделяемую в куче (heap), разработчик должен был освобождать самостоятельно.

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... какие-то операции ...
 if (some_condition) {
 return; // Утечка памяти! delete не вызывается
 }
 delete ptr;
}

В таком коде, если возникает исключение или происходит ранний возврат (early return), вызов delete пропускается, и происходит утечка памяти. Парадигма, предотвращающая это, называется «RAII» (Resource Acquisition Is Initialization — Получение ресурса есть инициализация). RAII — это метод, который связывает выделение ресурса с инициализацией объекта (конструктором), а освобождение ресурса — с уничтожением объекта (деструктором). Умные указатели — это набор классов стандартной библиотеки, применяющих идиому RAII к управлению памятью.

2. `std::unique_ptr`: Эксклюзивное владение с нулевыми накладными расходами

std::unique_ptr — это умный указатель, который обладает «эксклюзивным владением» (Exclusive Ownership) динамически выделенным объектом. В любой момент времени ресурсом может владеть только один unique_ptr.

2.1 Принцип нулевых накладных расходов

Главное преимущество std::unique_ptr — его производительность. В состоянии по умолчанию, без кастомного удалителя (custom deleter), размер std::unique_ptr абсолютно идентичен размеру сырого указателя (Raw Pointer). Он не имеет никаких лишних переменных-членов и не использует виртуальные функции. Благодаря оптимизациям компилятора, доступ через std::unique_ptr разворачивается в ассемблерный код, эквивалентный сырому указателю.

2.2 Перемещение владения и `std::move`

Поскольку std::unique_ptr обладает эксклюзивным владением, его нельзя копировать (конструктор копирования и оператор присваивания с копированием удалены с помощью delete). Чтобы передать владение другому unique_ptr, необходимо использовать семантику перемещения (Move Semantics) с помощью std::move.

 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();
 // При выходе из области видимости ptr уничтожается, и Resource также освобождается
}

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

 // process_resource(my_ptr); // Ошибка: копирование невозможно
 process_resource(std::move(my_ptr)); // Перемещение владения

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

Следующая диаграмма Mermaid демонстрирует концепцию перемещения владения с помощью std::move.

2.3 Реализация пользовательского удалителя (Custom Deleter)

При оборачивании устаревших API на C (например, FILE* или сокетов) для освобождения памяти необходимо вызывать функции, отличные от delete (например, fclose). В std::unique_ptr можно указать пользовательский удалитель в качестве второго параметра шаблона.

 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>

// Функтор для пользовательского удалителя
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());
 }
 // При выходе из области видимости вызывается FileDeleter и выполняется fclose
 return 0;
}

Использование указателей на функции или лямбда-выражений в качестве пользовательского удалителя может увеличить размер unique_ptr, однако при использовании функционального объекта без состояния (Functor), как показано выше, благодаря EBCO (Empty Base Class Optimization) в C++ или [[no_unique_address]] в C++20, размер не будет превышать размер сырого указателя (поддерживаются нулевые накладные расходы).

3. `std::shared_ptr`: Совместное владение и управляющий блок

std::shared_ptr — это умный указатель, предназначенный для совместного владения одним объектом несколькими указателями. Управляемый объект освобождается, когда уничтожается последний shared_ptr, указывающий на него.

3.1 Внутренняя архитектура: Управляющий блок

Помимо указателя на управляемый объект, std::shared_ptr выделяет в куче и совместно использует метаданные, называемые управляющим блоком (Control Block). Управляющий блок содержит следующую информацию:

Strong Count (Счетчик сильных ссылок): Количество shared_ptr, владеющих объектом. Когда он становится равен 0, объект уничтожается.
Weak Count (Счетчик слабых ссылок): Количество weak_ptr, наблюдающих за объектом. Когда и Strong Count, и Weak Count становятся равны 0, освобождается сам управляющий блок.
Пользовательский удалитель и аллокатор (если они указаны).

Поэтому размер самого объекта std::shared_ptr обычно в два раза больше сырого указателя (указатель на объект и указатель на управляющий блок).

3.2 Производительность и атомарные операции

Счетчики ссылок в управляющем блоке реализованы с помощью атомарных операций (Atomic Operations), чтобы их можно было безопасно увеличивать и уменьшать в многопоточной среде.

На архитектурах x86/x64 для инкремента и декремента счетчика ссылок используются атомарные инструкции, такие как lock xadd. Это влечет за собой накладные расходы в десятки тактов по сравнению с обычным целочисленным сложением. Следовательно, передача shared_ptr в функцию по значению вызывает атомарный инкремент и декремент при каждом копировании, что снижает производительность.

Лучшая практика (Best Practice): При передаче shared_ptr в функцию его следует передавать как константную ссылку (const std::shared_ptr<T>&) или передавать сырой указатель/ссылку, если нет необходимости разделять владение.

3.3 `std::make_shared` против `new`

При создании shared_ptr следует по возможности использовать std::make_shared. Для этого есть две веские причины.

Оптимизация выделения памяти: При использовании new происходят две аллокации в куче: для самого объекта и для управляющего блока. Использование std::make_shared позволяет выделить один большой блок памяти, содержащий оба компонента, за одну аллокацию, что также улучшает эффективность кэширования.
Безопасность исключений (Exception Safety): В стандартах до C++17 порядок вычисления аргументов функции не был строго определен. Если при вычислении других аргументов возникало исключение до того, как выделенный с помощью new указатель передавался в конструктор shared_ptr, существовал риск утечки памяти. make_shared полностью решает эту проблему.

1
2
3
4
5


// Код, которого следует избегать (2 аллокации памяти)
std::shared_ptr<MyClass> ptr1(new MyClass());

// Рекомендуемый код (1 аллокация памяти)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: Разрешение циклических ссылок и наблюдение

Совместное владение имеет критическую уязвимость — «циклические ссылки» (Circular References). Если объект A и объект B ссылаются друг на друга с помощью shared_ptr, их Strong Count будет поддерживаться как минимум на уровне 1. Они никогда не станут равны 0 до завершения программы, что приведет к утечке памяти.

graph TD subgraph "Циклическая ссылка (Утечка памяти)" A["Объект A"] -->|"shared_ptr (Strong=1)"| B["Объект B"] B -->|"shared_ptr (Strong=1)"| A end

4.1 Разрыв цикла с помощью `std::weak_ptr`

Эту проблему решает std::weak_ptr. weak_ptr создается из shared_ptr и ссылается на объект, но не увеличивает Strong Count. Вместо этого он увеличивает Weak Count. Это позволяет «наблюдать» за объектом, не владея им.

graph TD subgraph "Разрыв циклической ссылки" C["Объект A"] -->|"shared_ptr (Strong=1)"| D["Объект B"] D -.->|"weak_ptr (Weak=1)"| C end

4.2 Безопасный доступ с помощью метода `lock()`

weak_ptr не имеет операторов прямого доступа к объекту (-> и *), поскольку целевой объект уже может быть уничтожен. Для безопасного доступа необходимо временно получить shared_ptr, вызвав метод lock().

 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 для предотвращения циклических ссылок

 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 из weak_ptr для доступа
 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 и nodeB корректно уничтожаются
}

5. Ограничения совместного владения в многопоточной среде

Потокобезопасность shared_ptr часто понимают неправильно. Хотя «обновление счетчиков ссылок в управляющем блоке является потокобезопасным», «чтение и запись самого объекта shared_ptr потоконебезопасны».

Безопасные операции: Несколько потоков читают/пишут свои собственные экземпляры shared_ptr (но разделяют один и тот же управляющий блок).
Состояние гонки (опасно): Несколько потоков одновременно читают/пишут один и тот же экземпляр shared_ptr.

Если один и тот же экземпляр должен совместно использоваться несколькими потоками, необходимо применять std::atomic<std::shared_ptr<T>> (C++20) или защищать его мьютексом (std::mutex).

6. Математическая формулировка подсчета ссылок

Жизненный цикл в управляющем блоке можно математически выразить следующим образом. Пусть $S(t)$ — Strong Count в момент времени $t$, а $W(t)$ — Weak Count.

Начальное состояние (сразу после make_shared):

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

При копировании (создании дубликата shared_ptr):

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

Условие уничтожения управляемого объекта (Managed Object):

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

Условие освобождения памяти самого управляющего блока (Control Block):

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

То есть,

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

Как показывают эти формулы, пока существует weak_ptr ($W(t) > 0$), небольшая область памяти для управляющего блока продолжает существовать, даже если управляемый объект уничтожен. В некоторых случаях это может стать единственным недостатком make_shared (поскольку память управляемого объекта и управляющий блок объединены, наличие слабой ссылки препятствует возвращению в систему огромного блока памяти, выделенного под управляемый объект), но обычно преимущества в производительности make_shared значительно перевешивают.

7. Заключение

Управление памятью в Modern C++ больше не требует ручного манипулирования new/delete.

По умолчанию всегда используйте std::unique_ptr, внедряя в дизайн четкое владение с нулевыми накладными расходами.
Используйте std::shared_ptr только тогда, когда жизненный цикл объекта действительно должен быть разделен между несколькими владельцами, и создавайте его с помощью std::make_shared.
Для реализации структур данных или паттерна “Наблюдатель” (Observer), где могут возникать циклы совместного владения (циклические ссылки), применяйте std::weak_ptr, чтобы предотвратить утечки памяти.

Глубокое понимание умных указателей и их применение в подходящих ситуациях позволяет создавать безопасную и надежную архитектуру программного обеспечения без каких-либо потерь в производительности C++.

Modern C++ on kenji.blog

Введение в многопоточное программирование и асинхронную обработку на C++ (std::async)

1. Основы параллельной обработки и закон Амдала

2. Основы потоков: std::thread и std::jthread (C++20)

Традиционный std::thread (C++11)

Современный std::jthread (C++20)

3. Предотвращение состояний гонки и синхронизация: мьютексы и блокировки

std::mutex и std::lock_guard

std::unique_lock

4. Взаимодействие между потоками: std::condition_variable

5. Высокоуровневая асинхронная обработка: std::future, std::promise, std::async

std::promise и std::future

Параллельная обработка на основе задач с помощью std::async