Modern C++ on kenji.blog

Introdução à Programação Multithreading e Processamento Assíncrono em C++ (std::async)

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

No desenvolvimento de software moderno, a programação multithreading é essencial para extrair o máximo de desempenho das CPUs multinúcleo. O C++ introduziu APIs de multithreading e processamento assíncrono (<thread>, <mutex>, <condition_variable>, <future>) como parte de sua biblioteca padrão a partir do C++11. Isso tornou possível implementar processamento concorrente seguro e portável sem a necessidade de escrever códigos dependentes de plataforma (como threads POSIX ou Windows API). Além disso, com cada nova atualização nas versões C++14, C++17 e C++20, foram adicionados recursos mais avançados e seguros, como std::scoped_lock e std::jthread.

Neste artigo, explicaremos de forma abrangente, com exemplos detalhados de código, desde os fundamentos da programação multithreading em C++ até os mecanismos de sincronização para evitar corridas de dados (data races) e os conceitos de processamento assíncrono moderno (std::async) e pools de threads.

1. Fundamentos de Processamento Concorrente e a Lei de Amdahl

O principal objetivo de adotar multithreading é a “melhoria de desempenho”, mas nem todo o programa pode ser paralelizado. Aqui entra a importância da Lei de Amdahl (Amdahl’s Law).

A Lei de Amdahl é um modelo que prevê quanto o desempenho de todo o sistema melhorará quando uma parte do programa for paralelizada e acelerada.

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

$S(N)$ : Taxa teórica máxima de aceleração (speedup)
$P$ : Proporção da parte paralelizável em relação a todo o programa (0 ≤ $P$ ≤ 1)
$N$ : Número de processadores (threads)

Um fato importante demonstrado por esta fórmula é que “não importa o quanto se aumente o número de processadores $N$, a parte sequencial não paralelizável $(1 - P)$ se tornará um gargalo, impondo um limite para a aceleração”. Por exemplo, mesmo que $90\%$ do programa possa ser paralelizado ($P = 0.9$), desde que os $10\%$ restantes continuem sendo executados de forma sequencial, a aceleração máxima será de apenas $10$ vezes ($S(\infty) = 1 / 0.1$), mesmo utilizando um número infinito de processadores.

Portanto, ao realizar programação multithreading em C++, é necessário não apenas aumentar o número de threads, mas também projetar para reduzir ao mínimo as partes de processamento sequencial (como contenção de locks e overhead de sincronização).

2. Fundamentos de Threads: `std::thread` e `std::jthread` (C++20)

O Tradicional `std::thread` (C++11)

O std::thread, introduzido no C++11, é a classe mais básica para executar funções e expressões lambda em uma nova thread.

 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;

 // Criação e início de execução da thread
 std::thread t1(workerFunction, 1);

 // Criação de thread utilizando expressão lambda
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // Aguarda o término das threads (join)
 t1.join();
 t2.join();

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

Um ponto de atenção com o std::thread é que você deve sempre chamar join() ou detach() antes que ele seja destruído. Se o destrutor de std::thread for chamado sem que nenhum dos dois tenha sido invocado, std::terminate() será chamado e o programa sofrerá falha (crash). Para garantir segurança contra exceções, era necessário criar classes wrapper personalizadas utilizando o padrão RAII.

O Moderno `std::jthread` (C++20)

No C++20, o std::jthread (joining thread) foi introduzido resolvendo essas falhas. O std::jthread chama join() automaticamente em seu destrutor, de modo que ele pode esperar com segurança o término da thread mesmo quando ocorre uma exceção. Ele também possui uma funcionalidade de cancelamento cooperativo de thread por meio do 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
 // É possível detectar pedidos de cancelamento recebendo std::stop_token no primeiro argumento
 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));

 // Solicita o cancelamento de forma explícita
 jt.request_stop();

 // O join() manual não é necessário, pois o destrutor de jthread fará o join automaticamente
 return 0;
}

3. Evitando Corridas de Dados e Sincronização: Mutexes e Locks

Quando várias threads acessam simultaneamente a mesma área de memória (como uma variável) e pelo menos uma delas executa uma gravação, ocorre uma corrida de dados (Data Race). No padrão C++, uma corrida de dados resulta em um comportamento indefinido (Undefined Behavior). Para evitar isso, é necessário um controle de exclusão mútua usando std::mutex.

`std::mutex` e `std::lock_guard`

Chamar std::mutex::lock() e unlock() de forma manual não é recomendado porque, caso ocorra uma exceção, unlock() pode não ser chamado, resultando no risco de um deadlock (impasse). No C++, utilizamos o std::lock_guard (C++11) ou std::scoped_lock (C++17), que empregam o padrão 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) {
 // Será desbloqueado (unlocked) automaticamente ao sair do escopo
 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;
 // Será 100000 conforme esperado
 return 0;
}

`std::unique_lock`

O std::lock_guard é um lock simples baseado em escopo, mas se você precisar de um controle mais flexível (lock adiado, lock com limite de tempo, unlock no meio da execução, etc.), o std::unique_lock deve ser utilizado. O std::unique_lock é fundamental quando se usa a std::condition_variable, explicada a seguir.

4. Comunicação entre Threads: `std::condition_variable`

A std::condition_variable é utilizada para implementar conceitos como o “Padrão Produtor-Consumidor (Producer-Consumer Pattern)”, onde uma thread aguarda até que uma condição específica seja atendida, e outra thread envia uma notificação quando a condição é alcançada.

 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(); // Notifica o consumidor
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // Notifica o término
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // Aguarda até que a condição seja satisfeita (fila não estar vazia ou a flag de término estar ativada)
 // Especificando a condição com uma função lambda para prevenir falsos despertares (Spurious Wakeups)
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // Desbloqueia (unlock) para executar processamento pesado (aqui, apenas uma saída)
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // Obtém o lock novamente
 }

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

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

Neste exemplo, o std::condition_variable::wait coloca a thread para dormir (sleep state) até que as condições sejam alcançadas, prevenindo o consumo desnecessário de recursos da CPU (busy waiting).

5. Processamento Assíncrono de Alto Nível: `std::future`, `std::promise`, `std::async`

Embora std::thread e std::mutex, discutidos até agora, sejam poderosos, eles essencialmente trazem os mecanismos de thread de baixo nível do sistema operacional para o C++, o que geralmente resulta em código complexo ao lidar com a obtenção de resultados ou a propagação de exceções. Se você quiser executar processamento concorrente que possua valores de retorno, ou se necessitar de processamento assíncrono de nível mais alto, utilize as funcionalidades do cabeçalho <future>.

`std::promise` e `std::future`

A std::promise representa o lado que “define” o resultado, e o std::future representa o lado que “recebe” o resultado. Eles atuam como um canal seguro para passar resultados ou exceções entre threads.

Processamento Concorrente Baseado em Tarefas Usando `std::async`

A forma mais recomendada para executar tarefas assíncronas em C++ é usar std::async. O std::async executa a tarefa de forma assíncrona e retorna um std::future para obtenção do resultado.

 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;

 // Especifica std::launch::async para forçar a execução em uma thread diferente
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

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

 try {
 // Ao chamar get(), ele bloqueará a thread atual e aguardará até que o cálculo seja concluído
 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;
}

O diagrama de sequência a seguir mostra o comportamento do std::async.

sequenceDiagram participant Main as "Thread Principal" participant Async as "Trabalhador std::async" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "Fazer outro trabalho..." Main->>Async: "future.get() (Bloqueia até estar pronto)" Note right of Async: "Cálculos..." Async-->>Main: "Retornar Resultado ou Lançar Exceção" deactivate Async

O primeiro argumento de std::async é a Política de Lançamento (Launch Policy), que possui os dois tipos a seguir:

std::launch::async: Executa de forma assíncrona, garantindo a criação de uma nova thread (ou sua alocação através de um pool de threads).
std::launch::deferred: Avaliação preguiçosa (lazy evaluation). É executado de forma síncrona na thread chamadora no exato momento em que future.get() ou future.wait() for invocado.

O padrão (quando não especificado) depende da implementação, e uma das opções será escolhida com base nas condições de carga do sistema. Se você deseja garantir que será executado de forma assíncrona, especifique explicitamente std::launch::async.

6. Conceito de Pool de Threads (Thread Pool)

Chamar std::async repetidamente ou criar e destruir um std::thread em cada iteração de um loop gera um overhead significativo de troca de contexto de threads (context switch) e alocação de recursos do SO que não pode ser ignorado. A utilização de um pool de threads (Thread Pool) é essencial, principalmente ao lidar com uma grande quantidade de pequenas tarefas (Fine-grained tasks).

O pool de threads é uma arquitetura onde um determinado número de threads trabalhadoras (Workers) são geradas antecipadamente quando o aplicativo é iniciado. As tarefas são acumuladas em uma fila (Queue) e, então, processadas sequencialmente por threads trabalhadoras que estiverem ociosas.

A biblioteca padrão do C++ (até o C++23) não possui uma classe de pool de threads padronizada. Entretanto, combinando std::thread, std::mutex, std::condition_variable, std::function e std::packaged_task, é possível implementar um pool de threads eficiente em algumas dezenas de linhas de código. Em aplicações reais, também é comum usar E/S assíncrona do Boost.Asio e bibliotecas de terceiros.

7. Considerações sobre Desempenho e Escalabilidade

Para obter o melhor desempenho da programação multithreading, é necessário prestar atenção não só na paralelização do código, mas também na arquitetura do hardware.

Falso Compartilhamento (False Sharing): Mesmo que várias threads estejam atualizando variáveis diferentes, se essas variáveis estiverem localizadas na mesma linha de cache da CPU (geralmente 64 bytes), ocorrerá uma sincronização desnecessária de memória para manter a coerência de cache, resultando numa redução drástica no desempenho. Para prevenir isso, é necessário usar o especificador alignas para organizar as variáveis nos limites das linhas de cache.
Programação sem Bloqueios (Lock-Free) e std::atomic: Para evitar o overhead do lock/unlock de mutexes, pode-se considerar a introdução de estruturas de dados lock-free ou operações indivisíveis (como Compare-And-Swap) utilizando <atomic>. No entanto, como isto requer um entendimento correto da ordem de memória (std::memory_order) e a dificuldade de implementação é muito alta, isto geralmente é adotado apenas quando considerado indispensável após avaliações de desempenho rigorosas.

8. Conclusão

Nós abordamos sobre a programação multithreading e assíncrona em C++, desde os fundamentos até os mais recentes recursos do C++20. Os pontos cruciais são os seguintes:

Basicamente, use std::async: Para tarefas assíncronas isoladas ou processamento concorrente que retorna resultados, utilize std::async e std::future, pois eles são mais seguros do que gerenciar threads manualmente.
Utilize std::jthread para gerenciar threads: Para threads que serão executadas a longo prazo em background, utilize o std::jthread do C++20 para garantir um processo seguro de finalização.
Use RAII para sincronização: O bloqueio (lock) de um mutex para evitar corridas de dados (data races) deve ser invariavelmente realizado por intermédio de std::lock_guard ou std::unique_lock.
Tenha em mente o overhead: Evite a criação excessiva de threads e implante uma arquitetura de pool de threads, se for necessário.

Bugs em processos concorrentes (como deadlocks e data races) possuem baixa reprodutibilidade e estão entre os mais difíceis de depurar. Tenha a segurança das threads (thread-safety) sempre em mente e realize o desenvolvimento de sistemas robustos e velozes usando o C++ moderno ao optar pelas ferramentas apropriadas na biblioteca padrão.

Técnicas de uso de smart pointers (std::unique_ptr / shared_ptr) para evitar vazamentos de memória

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

O gerenciamento de memória em C++ tem sido, por muitos anos, um dos maiores desafios para os desenvolvedores. O estilo tradicional de gerenciamento de memória, que depende de new e delete manuais, tornou-se um terreno fértil para a criação de bugs graves, como vazamentos de memória, ponteiros pendentes (dangling pointers) e dupla liberação. No entanto, com a chegada do Modern C++ (C++11 em diante), a situação mudou drasticamente. No centro dessa mudança estão os “Smart Pointers” (Ponteiros Inteligentes).

Neste artigo, explicaremos de forma extremamente detalhada os mecanismos e técnicas avançadas de uso do std::unique_ptr, std::shared_ptr e std::weak_ptr - ferramentas poderosas para erradicar vazamentos de memória e realizar um gerenciamento de recursos seguro e eficiente. Abordaremos suas implementações internas (blocos de controle e operações atômicas), impacto no desempenho e a formulação da contagem de referências por meio de modelos matemáticos.

1. Introdução: A era sombria do gerenciamento de memória em C++ e o alvorecer do Modern C++

No desenvolvimento C++ do passado, a memória alocada no heap precisava ser liberada pelo próprio desenvolvedor, sob sua própria responsabilidade.

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... algum processamento ...
 if (some_condition) {
 return; // Ocorre um vazamento de memória! delete não é chamado
 }
 delete ptr;
}

Em códigos como o acima, o delete é ignorado e ocorre um vazamento de memória se houver uma exceção ou um retorno antecipado. O paradigma para evitar isso é o “RAII (Resource Acquisition Is Initialization)”. O RAII é uma técnica que vincula a aquisição de recursos à inicialização do objeto (construtor) e a liberação de recursos à destruição do objeto (destrutor). Os smart pointers são um conjunto de classes da biblioteca padrão que aplicam este idioma RAII ao gerenciamento de memória.

2. `std::unique_ptr`: Propriedade exclusiva com zero overhead

O std::unique_ptr é um smart pointer que possui “Propriedade Exclusiva (Exclusive Ownership)” sobre um objeto alocado dinamicamente. Sempre haverá apenas um unique_ptr que possui um determinado recurso.

2.1 Princípio do zero overhead

A maior vantagem do std::unique_ptr é o seu desempenho. No seu estado padrão (sem possuir um custom deleter), o tamanho de um std::unique_ptr é perfeitamente idêntico ao de um ponteiro bruto (Raw Pointer). Ele não possui nenhuma variável membro desnecessária e funções virtuais não são utilizadas. Devido à otimização do compilador, o acesso feito por meio de um std::unique_ptr é expandido para o mesmo código assembly que o de um ponteiro bruto.

2.2 Transferência de propriedade e `std::move`

Por possuir propriedade exclusiva, o std::unique_ptr não pode ser copiado (o construtor de cópia e o operador de atribuição de cópia foram “deletados” usando delete). Para transferir a propriedade para outro unique_ptr, utilizamos a semântica de movimento (Move Semantics) através da função 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();
 // Ao sair do escopo, ptr é destruído e Resource também é liberado
}

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

 // process_resource(my_ptr); // Erro: cópia não permitida
 process_resource(std::move(my_ptr)); // Transferência de propriedade

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

O diagrama Mermaid a seguir mostra o conceito de transferência de propriedade usando std::move.

2.3 Implementação de custom deleters

Ao encapsular APIs legadas em C (por exemplo, FILE* ou sockets), muitas vezes precisamos chamar uma função diferente de delete (como fclose) para liberar a memória. O std::unique_ptr permite especificar um “custom deleter” (deletador personalizado) no seu segundo argumento de template.

 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>

// Functor para o custom 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());
 }
 // Ao final do escopo, FileDeleter é chamado e fclose é executado
 return 0;
}

Usar ponteiros de função ou expressões lambda como custom deleters pode aumentar o tamanho do unique_ptr. No entanto, ao usar um objeto de função (Functor) sem estado como mostrado acima, o tamanho não aumentará em relação a um ponteiro bruto graças à EBCO (Empty Base Class Optimization) do C++ ou ao [[no_unique_address]] introduzido no C++20 (o zero overhead é mantido).

3. `std::shared_ptr`: Propriedade compartilhada e bloco de controle

O std::shared_ptr é um smart pointer para compartilhar a propriedade de um mesmo objeto entre múltiplos ponteiros. Quando o último shared_ptr é destruído, o objeto gerenciado é liberado.

3.1 Arquitetura interna: O Bloco de Controle (Control Block)

Diferente do ponteiro para o objeto sendo gerenciado, o std::shared_ptr aloca e compartilha no heap metadados chamados de Bloco de Controle (Control Block). O bloco de controle contém as seguintes informações:

Strong Count (Contagem Forte): O número de instâncias de shared_ptr que possuem o objeto. Quando isso chega a 0, o objeto é destruído.
Weak Count (Contagem Fraca): O número de instâncias de weak_ptr que estão monitorando o objeto. Quando tanto a Strong Count quanto a Weak Count chegam a 0, o próprio bloco de controle é liberado.
Custom Deleter e Alocador (se especificados).

Por esse motivo, o tamanho do próprio objeto std::shared_ptr costuma ser o dobro de um ponteiro bruto (um ponteiro para o objeto e outro ponteiro para o bloco de controle).

3.2 Desempenho e operações atômicas

As contagens de referência no bloco de controle são implementadas como Operações Atômicas (Atomic Operations) para garantir incrementos e decrementos seguros, mesmo em um ambiente multithread.

Nas arquiteturas x86/x64, as instruções atômicas como lock xadd são usadas para incrementar ou decrementar a contagem de referências. Isso tem um overhead de dezenas de ciclos de clock quando comparado à simples adição de inteiros. Portanto, passar um shared_ptr por valor a uma função acarretará incrementos e decrementos atômicos a cada cópia, degradando o desempenho.

Melhor Prática: A menos que seja estritamente necessário compartilhar a propriedade, você deve passar o shared_ptr para uma função como const std::shared_ptr<T>& (referência const), ou passar como ponteiro/referência bruto.

3.3 `std::make_shared` vs `new`

Ao gerar um shared_ptr, você deve usar std::make_shared sempre que possível. Existem duas razões principais para isso.

Otimização de alocação de memória: Usar new resulta em duas alocações no heap: uma para o objeto em si e outra para o bloco de controle. Usar std::make_shared permite alocar de uma só vez um grande bloco de memória no heap que abrange a ambos, melhorando também a eficiência do cache.
Segurança contra exceções (Exception Safety): Nos padrões anteriores ao C++17, a ordem de avaliação dos argumentos da função não era definida, e se uma exceção ocorresse na avaliação de outros argumentos antes que o ponteiro alocado com new fosse passado para o construtor do shared_ptr, havia risco de vazamento de memória. O make_shared evita completamente este problema.

1
2
3
4
5


// Prática a ser evitada (2 alocações de memória)
std::shared_ptr<MyClass> ptr1(new MyClass());

// Prática recomendada (1 alocação de memória)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`: Resolvendo referências circulares e monitoramento

A propriedade compartilhada possui uma fraqueza fatal chamada “Referências Circulares (Circular References)”. Se o Objeto A e o Objeto B apontarem um para o outro com shared_ptr, a Strong Count de ambos será mantida em pelo menos 1, e como nunca chegará a 0 até o final do programa, ocorrerá um vazamento de memória.

graph TD subgraph "Referência Circular (Vazamento de Memória)" A["Objeto A"] -->|"shared_ptr (Forte=1)"| B["Objeto B"] B -->|"shared_ptr (Forte=1)"| A end

4.1 Quebrando ciclos com `std::weak_ptr`

O std::weak_ptr resolve este problema. O weak_ptr é gerado a partir de um shared_ptr e faz referência ao objeto, mas não incrementa a Strong Count. Em vez disso, ele incrementa a Weak Count. Isso permite “monitorar” o objeto sem ter a propriedade sobre ele.

graph TD subgraph "Quebrando a Referência Circular" C["Objeto A"] -->|"shared_ptr (Forte=1)"| D["Objeto B"] D -.->|"weak_ptr (Fraca=1)"| C end

4.2 Acesso seguro através do método `lock()`

O weak_ptr não possui operadores (como -> ou *) para acessar o objeto de forma direta. Isso ocorre porque existe a possibilidade do objeto de destino já ter sido destruído. Para acessar de forma segura, deve-se chamar o método lock() e obter temporariamente um shared_ptr.

 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; // Usa weak_ptr para evitar referência circular

 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;

 // Obtém o shared_ptr a partir do weak_ptr para o acesso
 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 e nodeB são adequadamente destruídos
}

5. Restrições da propriedade compartilhada em ambientes multithread

A segurança das threads (thread-safety) no shared_ptr costuma ser bastante incompreendida. “A atualização da contagem de referências dentro do bloco de controle é thread-safe”, no entanto “a leitura e escrita do próprio objeto shared_ptr não é thread-safe”.

Operação Segura: Múltiplas threads lendo e escrevendo, cada uma na sua própria instância do shared_ptr (mesmo que compartilhem o mesmo bloco de controle).
Data race (Perigo): Múltiplas threads lendo e escrevendo simultaneamente sobre a mesma exata instância do shared_ptr.

Caso precise compartilhar a mesma instância em várias threads, será necessário utilizar std::atomic<std::shared_ptr<T>> (C++20) ou protegê-la com um mutex (std::mutex).

6. Formulação matemática da contagem de referências

Expressando as transições de estados do ciclo de vida dentro do bloco de controle de maneira matemática, temos o seguinte. Seja $S(t)$ a Strong Count no tempo $t$ e $W(t)$ a Weak Count.

Estado inicial (logo após make_shared):

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

Quando ocorre uma cópia (duplicação de shared_ptr):

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

A condição para que o objeto gerenciado (Managed Object) seja destruído:

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

A condição para que o próprio bloco de controle (Control Block) seja liberado da memória:

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

Ou seja,

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

Como as fórmulas acima sugerem, contanto que um weak_ptr continue existindo ($W(t) > 0$), o pequeno espaço de memória para o bloco de controle continuará reservado, mesmo que o objeto gerenciado seja destruído. Esse seria o único cenário em que o uso do make_shared traria desvantagem (uma vez que a memória do objeto gerenciado e a do bloco de controle foram alocadas juntas, se restar alguma referência fraca, o grande espaço de memória destinado ao objeto gerenciado não retornará ao sistema). Contudo, na maior parte do tempo, a vantagem no desempenho do make_shared supera esse ponto negativo com folga.

7. Conclusão

O gerenciamento de memória em Modern C++ não está mais na época de fazer a gestão com new/delete manualmente.

Como padrão, use std::unique_ptr sempre, e incorpore no design a sua clara propriedade de exclusividade enquanto ganha as vantagens de ter zero overhead.
Use o std::shared_ptr apenas caso seja verdadeiramente necessário compartilhar o ciclo de vida entre vários proprietários, e utilize o std::make_shared para instanciá-lo.
Faça bom uso do std::weak_ptr para a implementação do padrão de observador (Observer Pattern) e estruturas de dados que tendem a causar ciclos na propriedade (referências circulares), para, assim, prevenir vazamentos de memória antes que eles aconteçam.

Através do profundo entendimento dos smart pointers e de suas corretas aplicações nos lugares adequados, torna-se possível erguer uma arquitetura de software segura e sólida sem abrir mão de nenhuma das partes da alta performance da linguagem C++.

Modern C++ on kenji.blog

Introdução à Programação Multithreading e Processamento Assíncrono em C++ (std::async)

1. Fundamentos de Processamento Concorrente e a Lei de Amdahl

2. Fundamentos de Threads: std::thread e std::jthread (C++20)

O Tradicional std::thread (C++11)

O Moderno std::jthread (C++20)

3. Evitando Corridas de Dados e Sincronização: Mutexes e Locks

std::mutex e std::lock_guard

std::unique_lock

4. Comunicação entre Threads: std::condition_variable

5. Processamento Assíncrono de Alto Nível: std::future, std::promise, std::async

std::promise e std::future

Processamento Concorrente Baseado em Tarefas Usando std::async