What are some common pitfalls when working with pointers in multithreaded applications?

Question

Ryan McCombe · Accepted Answer

Working with pointers in multithreaded applications can be tricky and introduce various issues if not handled carefully. Here are some common pitfalls and how to avoid them:

Race Conditions

Race conditions occur when multiple threads access shared data concurrently, and at least one thread modifies the data.

1#include <iostream>
2#include <thread>
3#include <vector>
4
5class SharedResource {
6 public:
7  int* data{nullptr};
8};
9
10void modifyData(SharedResource* resource) {
11  if (resource->data == nullptr) {
12    resource->data = new int(42);  
13  }
14  (*resource->data)++;  
15}
16
17int main() {
18  SharedResource resource;
19  std::vector<std::thread> threads;
20
21  for (int i = 0; i < 10; ++i) {
22    threads.emplace_back(modifyData, &resource);
23  }
24
25  for (auto& t : threads) {
26    t.join();
27  }
28
29  std::cout << "Final value: "
30    << *resource.data << "\n";
31  delete resource.data;
32}

1Final value: 51

This code has multiple issues:

Multiple threads might try to initialize data simultaneously.
Incrementing resource->data is not atomic and can lead to lost updates.

To fix this, use proper synchronization mechanisms like mutexes:

1#include <iostream>
2#include <mutex>
3#include <thread>
4#include <vector>
5
6class SharedResource {
7 public:
8  int* data{nullptr};
9  std::mutex mutex;
10};
11
12void modifyData(SharedResource* resource) {
13  std::lock_guard<std::mutex> lock(
14    resource->mutex
15  );
16  if (resource->data == nullptr) {
17    resource->data = new int(42);
18  }
19  (*resource->data)++;
20}
21
22int main() {
23  SharedResource resource;
24  std::vector<std::thread> threads;
25
26  for (int i = 0; i < 10; ++i) {
27    threads.emplace_back(modifyData, &resource);
28  }
29
30  for (auto& t : threads) {
31    t.join();
32  }
33
34  std::cout << "Final value: "
35    << *resource.data << "\n";
36  delete resource.data;
37}

1Final value: 52

Dangling Pointers

Dangling pointers occur when a pointer refers to memory that has been deallocated. This is particularly dangerous in multithreaded contexts:

1#include <iostream>
2#include <thread>
3
4class Resource {
5 public:
6  int value{42};
7};
8
9Resource* globalResource = nullptr;
10
11void createResource() {
12  globalResource = new Resource();
13}
14
15void useResource() {
16  std::this_thread::sleep_for(
17    std::chrono::milliseconds(10));
18  if (globalResource) {
19    std::cout << globalResource->value << "\n";  
20  }
21}
22
23void deleteResource() {
24  delete globalResource;
25  globalResource = nullptr;
26}
27
28int main() {
29  std::thread t1(createResource);
30  std::thread t2(useResource);
31  std::thread t3(deleteResource);
32
33  t1.join();
34  t2.join();
35  t3.join();
36}

This code might crash if deleteResource runs before useResource. To fix this, use proper synchronization and consider using smart pointers:

1#include <iostream>
2#include <memory>
3#include <mutex>
4#include <thread>
5
6class Resource {
7 public:
8  int value{42};
9};
10
11std::shared_ptr<Resource> globalResource;
12std::mutex resourceMutex;
13
14void createResource() {
15  std::lock_guard<std::mutex> lock(resourceMutex);
16  globalResource = std::make_shared<Resource>();
17}
18
19void useResource() {
20  std::this_thread::sleep_for(
21    std::chrono::milliseconds(10));
22  std::lock_guard<std::mutex> lock(resourceMutex);
23  if (globalResource) {
24    std::cout << globalResource->value << "\n";
25  }
26}
27
28void deleteResource() {
29  std::lock_guard<std::mutex> lock(resourceMutex);
30  globalResource.reset();
31}
32
33int main() {
34  std::thread t1(createResource);
35  std::thread t2(useResource);
36  std::thread t3(deleteResource);
37
38  t1.join();
39  t2.join();
40  t3.join();
41}

Memory Leaks

Memory leaks can occur if a thread responsible for freeing memory terminates unexpectedly:

1#include <chrono>
2#include <thread>
3
4void leakyFunction() {
5  int* data = new int[1000];
6  std::this_thread::sleep_for(
7    std::chrono::seconds(1));
8  // Thread might be terminated before
9  // reaching this point
10  delete[] data;  
11}
12
13int main() {
14  std::thread t(leakyFunction);
15  std::this_thread::sleep_for(
16    std::chrono::milliseconds(500));
17
18  // Detaching the thread,
19  // potentially causing a leak
20  t.detach();
21}

To prevent this, use RAII (Resource Acquisition Is Initialization) principles and smart pointers:

1#include <chrono>
2#include <memory>
3#include <thread>
4
5void safeFunction() {
6  auto data = std::make_unique<int[]>(1000);
7  std::this_thread::sleep_for(
8    std::chrono::seconds(1));
9  // Memory will be automatically freed when
10  // the unique_ptr goes out of scope
11}
12
13int main() {
14  std::thread t(safeFunction);
15  std::this_thread::sleep_for(
16    std::chrono::milliseconds(500));
17  t.detach();
18}

Conclusion

When working with pointers in multithreaded applications:

Use proper synchronization mechanisms (mutexes, atomic operations).
Prefer smart pointers over raw pointers.
Use RAII to manage resource lifetimes.
Be cautious with global or shared pointers.
Consider using thread-safe data structures from the standard library.

Remember, multithreading adds complexity to pointer management. Always design your multithreaded code carefully and consider thread safety at every step.

Pointers

Pointers in Multithreaded Code

Race Conditions

Dangling Pointers

Memory Leaks

Conclusion

Pointers

Intro to C++ Programming

Questions & Answers