Managing C++ Threads: Creation, Joining, and Detaching

What is std::thread? An RAII Handle

Think of a std::thread object not as the thread itself, but as a C++ handle to the underlying OS thread of execution (the kernel task we discussed). This is a crucial distinction. The std::thread object follows the RAII (Resource Acquisition Is Initialization) idiom:

• Acquisition: Creating a std::thread object acquires and starts an OS thread.
• Release: The std::thread object's destructor is responsible for ensuring the OS thread resource is handled properly before the handle goes out of scope.

We will see that this "release" step is something you must manage explicitly.

Creating and Starting a Thread

Creating a thread is straightforward: you construct a std::thread object and pass it a callable entity (like a function or lambda) and its arguments. A key point to remember is that the new thread begins execution immediately upon the construction of the std::thread object. There is no separate .start() method as in some other languages.

Here's a simple example:

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

void do_work(int id, int delay_ms) {
    std::cout << "Thread " << id << " starting work." << std::endl;
    std::this_thread::sleep_for(std::chrono::milliseconds(delay_ms));
    std::cout << "Thread " << id << " finished work." << std::endl;
}

int main() {
    std::cout << "Main thread starting child thread." << std::endl;
    std::thread worker(do_work, 1, 500); // Create and start the thread

    // Let's discuss what needs to go here...
    
    worker.join(); // We'll get to this shortly
    std::cout << "Main thread finished." << std::endl;
    return 0;
}

In this code, the worker thread is created and immediately starts running the do_work function with arguments 1 and 500.

The Argument Passing Pitfall: Why std::ref is Necessary

This brings us to a critical "under the hood" detail that aligns perfectly with your goal of understanding C++ internals. What happens if you try to pass an argument by reference to a thread function?

Consider this:

void increment(int& value) {
    value++;
}

int main() {
    int my_value = 10;
    std::thread t(increment, my_value); // This will NOT compile!
    t.join();
    // if it did compile, would my_value be 11?
}

This code fails to compile. The reason is subtle and reveals how std::thread is designed for safety. The constructor of std::thread is a variadic template that, by default, copies or moves its arguments into internal storage. It does this to prevent dangerous situations where a thread might operate on a reference to a variable that has gone out of scope (e.g., a local variable in the parent thread).

This "decay-copy" mechanism strips the reference-ness from the arguments. To understand precisely why this happens, we need to look at the typical implementation of the std::thread constructor.

As the article explains, the arguments are decayed, which turns an int& into an int, and a copy is made. To pass a true reference, you must wrap the argument in std::ref, which creates a std::reference_wrapper. This wrapper is a copyable object, but it holds a pointer to the original variable, and the thread machinery knows how to unwrap it to get the reference on the other side.

The correct way to write the previous example is:

#include <iostream>
#include <thread>
#include <functional> // Required for std::ref

void increment(int& value) {
    value++;
}

int main() {
    int my_value = 10;
    std::thread t(increment, std::ref(my_value)); // Correct!
    t.join();
    std::cout << "Final value: " << my_value << std::endl; // Prints "Final value: 11"
    return 0;
}

Managing the Lifecycle: join() and detach()

Once a thread is launched, you have two choices for managing its lifecycle, represented by two std::thread member functions: join() and detach(). You must call one of them.

join(): Waiting for Completion

Calling join() on a std::thread object blocks the calling thread (e.g., main) until the thread represented by the object finishes its execution. This is how you synchronize the completion of a child thread with its parent.

• Once join() returns, the OS thread has finished, and the std::thread object is no longer associated with it.
• A std::thread object that can be joined is called joinable. After join() is called, it becomes non-joinable.
• Calling join() on a non-joinable thread is an error that will terminate your program. You can check with the joinable() member function.

detach(): Letting Go

Calling detach() severs the connection between the std::thread object and its underlying OS thread. The C++ object becomes non-joinable, and the OS thread is now a "daemon" thread. It will continue to run in the background. Its resources will be reclaimed by the OS when it finishes, but you can no longer communicate with it or wait for it.

This is dangerous. If main() finishes and the program exits, all detached threads are abruptly terminated, regardless of what they are doing. This can lead to corrupted files, inconsistent state, and other hard-to-debug problems.

The following video demonstrates these concepts practically.

The Cardinal Rule: A std::thread's Destructor is Strict

This brings us to the most important rule of std::thread lifetime management. When a std::thread object's destructor is called (e.g., it goes out of scope), it checks if the thread is still joinable.

If it is joinable (meaning you have called neither join() nor detach()), the destructor will call std::terminate(), aborting your entire program.

This is a deliberate, safety-first design choice. A joinable std::thread object being destroyed would leave an active OS thread unmanaged—a leaked resource. C++ prevents this by making it a fatal error.

int main() {
    std::thread t([]{
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "Thread finished." << std::endl;
    });
    // No join() or detach()
    return 0;
}

int main() {
    std::thread t([]{
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "Thread finished." << std::endl;
    });
    t.detach();
    std::cout << "Main finished." << std::endl;
    return 0;
}

int main() {
    std::thread t([]{
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "Thread finished." << std::endl;
    });
    t.join();
    t.join(); // Called a second time
    return 0;
}

Conclusion

You now have the fundamental tools to manage C++ threads. We've seen that std::thread is more than just a function call; it's a resource handle whose lifecycle you are responsible for.

Key Takeaways:

• A std::thread object is a handle to an OS thread; creating it starts execution immediately.
• Arguments to a thread's function are copied by default for safety. To pass a true reference, you must use std::ref.
• You must manage a thread's lifecycle:
  • join(): To wait for the thread to complete.
  • detach(): To let it run independently (use with caution).
• The Golden Rule: The destructor of a std::thread will call std::terminate() if the thread is still joinable. Always ensure you call either join() or detach() before the std::thread object is destroyed.

What's Next?

We've learned how to launch multiple threads of execution. This power comes with new challenges. When multiple threads try to access and modify the same data (like a shared counter or a queue), we can get unpredictable results. This problem is called a race condition. In our next lesson, we will analyze race conditions at the memory level and introduce the most fundamental synchronization primitive for preventing them: the std::mutex.