Practical Multithreading Best Practices: C++ Edition — Eliminating Accidents by Structure with RAII and jthread

“A design that worked fine in C# started crashing occasionally once we ported it to C++.” “We used std::thread, and when an exception was thrown the whole application died instantly via terminate.” “We were stopping things with a volatile bool flag, but in release builds only, it wouldn’t stop.” — C++ multithreading carries a danger that managed languages simply don’t have: a data race is, as-is, undefined behaviour (UB). It isn’t just that you might read a corrupted value; the compiler’s optimisation assumptions collapse, and you end up in a state where literally anything can happen.

This article is the C++ edition of our practical multithreading series. Aimed at developers writing business applications, equipment control software, and DLLs in modern C++ (C++17/20), it translates the general principles of multithread design — don’t add threads directly, reduce shared mutable state, apply lock discipline, design how things stop before anything else — into C++ and Windows tooling, alongside pitfalls specific to C++, all grounded in primary sources as of August 2026. It is written to stand on its own. The same principles worked out for other languages are also covered in the “.NET Edition”, “C Edition”, and “Java Edition”.

1. The Bottom Line First

• In C++, a data race is not “you might read a corrupted value” — it’s undefined behaviour. Leaving not a single unsynchronised shared mutable access anywhere in the code is an absolute requirement, more so than in other languages.¹
• Don’t use std::thread bare. If a std::thread’s destructor runs while the thread is still joinable, std::terminate kills the process instantly. C++20’s std::jthread automatically joins in its destructor and has a stop request mechanism (stop_token) built in.²³
• Always hold locks through RAII. Stop hand-writing mtx.lock(); use lock_guard / scoped_lock instead. The destructor reliably releases the lock even if an exception is thrown. When acquiring several locks at once, scoped_lock takes care of it with a deadlock-avoidance algorithm.⁴
• volatile is not a synchronisation tool. Use std::atomic for shared flags and counters, and std::mutex to protect multiple variables together. std::atomic provides both atomicity and ordering based on memory_order.⁵
• Do rendezvous waiting with condition_variable’s predicate-form wait. Condition variables are subject to spurious wakeups (waking without being notified), so calling wait without a predicate is a breeding ground for bugs.⁶
• jthread + stop_token (C++20) is the basic shape for how to stop a thread. In environments predating that, build cooperative stopping by hand with std::atomic<bool> plus a condition variable. Treat forcible thread termination as something that simply does not exist in the C++ world.³
• Know that a future’s destructor can block before you use std::async. Discard the return value and you end up with the same effect as serial execution.⁷
• Win32 synchronisation objects only earn their place for “working with Win32 wait APIs” and “cross-process” scenarios. Everywhere else, writing against the standard library is the better choice for portability and maintainability.⁸

2. Why Multithreading Is Hard — Race Conditions, Deadlocks, and Undefined Behaviour

Boiled down, the problems multithreading introduces come in two kinds, regardless of language.

A race condition is a bug where the outcome depends on the order in which multiple threads reach a particular piece of code. The classic example is a shared counter: the single expression ++count breaks down at the machine-code level into three steps — read, add, write back. If two threads enter those three steps at the same time, one thread’s addition gets overwritten and lost by the other’s write-back. The result changes from run to run, and which result you get is unpredictable.

sequenceDiagram
    participant A as Thread A
    participant M as Shared variable count
    participant B as Thread B
    Note over M: count = 10
    A->>M: Read (10)
    B->>M: Read (10)
    A->>A: Add locally (11)
    B->>B: Add locally (11)
    A->>M: Write back (11)
    B->>M: Write back (11)
    Note over M: Two increments happened,<br/>yet count = 11 — Thread A's addition was lost

Figure 1: A classic race condition in which an increment on a shared counter is lost. If another thread interleaves during the three steps of ++count, whichever write-back happens last overwrites the other

A deadlock is a state where two threads each wait on a lock the other holds, so neither can proceed. Thread A holds lock 1 and waits for lock 2; thread B holds lock 2 and waits for lock 1 — that alone is enough for both to stop forever.

flowchart LR
    A["Thread A<br/>holding lock 1"] -->|"waiting to acquire lock 2"| B["Thread B<br/>holding lock 2"]
    B -->|"waiting to acquire lock 1"| A

Figure 2: The circular wait of a deadlock. The moment the waiting arrows form a ring, every thread in that ring stops forever

What makes both of these awkward is that they are timing-dependent. An interleaving that only hits once in tens of thousands of runs on a development machine can happen every single day on a customer’s machine, with a different core count and different timing. “It doesn’t reproduce with a debugger attached” and “it went away when I added logging” both happen because observation itself changes the timing — that is classic race-bug behaviour. That is exactly why every principle in this article points in one direction: reduce the places that need synchronisation, before worrying about synchronising them correctly.

2.1. In C++, a Data Race Is Directly Undefined Behaviour

On top of that, C++ has a further layer that other languages don’t. Under the C++ standard, if multiple threads access the same memory location without synchronisation and at least one of them writes, that is a data race, and it is undefined behaviour. The concurrency chapter of the C++ Core Guidelines (CP.2, “Avoid data races”) states this as the very first absolute rule.¹ Undefined behaviour is not the mild story of “you might read either the old value or the new one.” The compiler optimises on the premise that no data race exists, so behaviour that you could never predict from the source code — a condition check vanishing from a loop, writes being reordered or coalesced — legitimately occurs. The classic accident where “a volatile bool stop flag only fails to work in release builds” is a textbook case of exactly this.

2.2. RAII Is the Foundation

Another premise specific to C++ is exceptions and resource management. C++ has no finally; instead it has RAII (automatic release through destructors), and the multithreading toolset is designed on the assumption that you’ll use it. “Manage locks through an object’s lifetime”; “guarantee thread joining through an object’s lifetime too” — going along with that convention is the foundation for writing multithreaded C++ safely.

3. How to Start a Thread — the thread Trap, and jthread

3.1. The std::thread Destructor Is “Designed to Cause Accidents”

std::thread has a well-known trap. If its destructor runs while the thread is still joinable (neither joined nor detached), std::terminate is called and the process dies instantly.⁹

void process()
{
    std::thread worker([]{ HeavyWork(); });
    DoSomething();      // ← if an exception is thrown here...
    worker.join();      // ← join is never reached; worker's destructor calls terminate
}

Making this exception-safe required guaranteeing the join with try/catch — a distorted state of affairs in a RAII language where threads alone had to be managed by hand. C++20’s std::jthread solves this. Because its destructor automatically issues a stop request and then joins, the code above becomes exception-safe simply by switching to std::jthread.² On MSVC, <stop_token> and jthread are available from Visual Studio 2019 16.9 onwards.³

flowchart TB
    T["Thread has been started"] --> Q{"What happens<br/>when the scope exits?"}
    Q -->|"std::thread<br/>neither joined nor detached"| X["std::terminate<br/>process dies instantly"]
    Q -->|"std::thread<br/>already joined"| OK1["Joins safely"]
    Q -->|"std::jthread - C++20"| OK2["Automatic request_stop + join<br/>safe even if an exception is thrown"]

Figure 3: The lifetime of a thread object and how it ends. std::thread is specified to die instantly if you forget to join, so from C++20 onward, make jthread the default

As a rule, don’t use detach(). A thread that has lost any means of joining becomes a classic cause of shutdown crashes, racing against the destruction of static variables and the heap when the process exits.

3.2. Tools “Above the Thread Level” — async, future, and Parallel Algorithms

The .NET edition’s principle of “don’t create threads yourself” maps onto the following tools in C++.

• std::async + std::future: for a one-off async task and receiving its result. There is, however, an important quirk: the future (or the last shared_future) tied to a task launched via std::async blocks until completion if its destructor runs while the task is still incomplete.⁷ For work actually launched with std::launch::async, discarding the returned future is equivalent to synchronous execution at that point. Worse, if you don’t specify a launch policy, the implementation is free to choose deferred (lazy execution) by default, in which case, if nobody calls get() / wait(), the work is never executed at all and silently vanishes. If you want to guarantee concurrent execution, specify std::launch::async explicitly, and have the owner manage the future’s lifetime.
• PPL - Parallel Patterns Library - concurrency::parallel_for / parallel_for_each: applying work in parallel across every element of a collection. However, if the work in a single iteration is too small, fork/join overhead eats up the gains, so as a rule, parallelise at the outer loop.¹⁰
• C++17’s parallel algorithms - std::execution::par: on MSVC, the major algorithms are parallelised (not all of them).¹¹ Note that if an exception escapes element processing under an execution policy, std::terminate is called. Placing your own exception boundary (try/catch) inside the callback follows the same thinking as the thread boundary in Section 6.

The line drawn elsewhere — “waiting on I/O is not something you solve by adding threads” — still applies without change. For native Windows code, OVERLAPPED I/O and IOCP are the tools that catch that work (for the mechanics, see “The Depths of Windows I/O, Part 2”).

4. Reducing Shared Mutable State — Splitting, Passing by Value, const, and Queues

Contention only arises when “multiple threads” and “shared mutable data” are both present. The number of threads is dictated by requirements, so what design can cut down is the sharing. The means fall into three families — splitting, making things immutable, and handing data off — and here is how you write each in C++.

Split. In work like parallel aggregation, rather than having every thread write into a shared total, give each thread its own local subtotal and merge them once, at the end. Writes to the shared value drop from “every iteration” to “once per thread”, cutting both the synchronisation cost and the window for contention by orders of magnitude. That single merge step can be done with a std::mutex or with a fetch_add on a std::atomic — either is fine.

Pass by value. If you hand the data a thread needs to it by copy (or move) at start-up, that data becomes exclusively the thread’s, and no synchronisation is needed. Capturing lambdas by reference ([&]) and then touching a variable whose lifetime has ended is a common accident, so lambdas passed to threads should use explicit captures, by copy or move as a rule. That said, “copied, therefore exclusive” only holds when the value is a deep value graph containing no aliases such as pointers or shared_ptr. Copying a struct that contains a raw pointer still leaves whatever it points to shared.

Share as const. Data that is only ever read is safe to read from any number of threads at once. Configuration values, master data, computation inputs, and the like can be shared without synchronisation if you make them a const share that isn’t rewritten after construction (std::shared_ptr<const Config>, for example). One caveat: what shared_ptr<const T> forbids is only mutation through that particular handle. If a non-const alias survives somewhere else, or a mutable member gets rewritten, contention remains — so design for that too, right down to “once construction is finished, release the non-const reference and let nobody write to it afterwards.” Simply deciding that “when a change is needed, build a new object and swap it in, rather than mutating in place” removes one piece of mutable state you’d otherwise have to guard (for the lifetime management of the swap itself, see the caution in Section 5.2).

Hand off through a queue. Route the flow of data between threads through a producer/consumer queue rather than a shared variable. The C++ standard has no channel type, so writing a small queue with std::mutex + std::condition_variable is the established pattern.

template <typename T>
class BlockingQueue {
public:
    explicit BlockingQueue(std::size_t capacity) : capacity_(capacity)
    {
        if (capacity == 0)                          // capacity 0 is a trap where every Push waits forever
            throw std::invalid_argument("capacity must be positive");
    }

    // Waits until there is room (or a stop request) if full. false means a stop request.
    bool Push(T item, std::stop_token st)
    {
        {
            std::unique_lock lock(mtx_);
            if (!not_full_.wait(lock, st, [this]{ return queue_.size() < capacity_; }))
                return false;                       // woken by a stop request
            if (st.stop_requested())                // if room and stop happen together, prefer stop,
                return false;                       // and refuse pushes once stopping has begun
            queue_.push(std::move(item));
        }
        not_empty_.notify_one();   // notify outside the lock
        return true;
    }

    // Waits for a stop request (stop_token) or an item to arrive. nullopt when stopped.
    std::optional<T> Pop(std::stop_token st)
    {
        std::optional<T> item;
        {
            std::unique_lock lock(mtx_);
            if (!not_empty_.wait(lock, st, [this]{ return !queue_.empty(); }))
                return std::nullopt;                // woken by a stop request
            if (st.stop_requested())                // if an item and stop happen together, prefer stop,
                return std::nullopt;                // and don't start new work once stopping has begun
            item = std::move(queue_.front());
            queue_.pop();
        }
        not_full_.notify_one();
        return item;
    }

private:
    const std::size_t capacity_;
    std::mutex mtx_;
    std::condition_variable_any not_empty_;   // condition_variable_any, to use the stop_token-aware wait
    std::condition_variable_any not_full_;
    std::queue<T> queue_;
};

There are two design points here. First, cap the capacity and make the producer side wait when full. A queue with no upper bound becomes a time bomb in setups where production outruns consumption: it “keeps running”, but memory keeps growing. Having Push block when full acts as natural backpressure, mechanically propagating overload upstream. Second, because condition variables are subject to spurious wakeups (waking without a notification), always call wait with a predicate. The predicate form of wait runs the “loop until the condition is true” logic for you internally.⁶

5. Lock Discipline — RAII and scoped_lock

Even after reducing shared mutable state, you often can’t get it to zero. Use exclusion for what remains shared, but locking without discipline only hides contention.

First, think of the unit of locking not as a “stretch of code” but as “data”. Assign one mutex to each set of mutable data you want to protect (make it a private member, not exposed outside), and take that same mutex at every place that touches that data — a broken version of this correspondence table is what most race bugs actually are. And the only thing you may do while holding a lock is read and write the data it protects. File I/O, network calls, and callbacks (calls into external code) while holding a lock don’t just extend how long you hold it — they open a path where the callee tries to take a different lock and deadlocks. Prepare outside the lock, and inside the lock do nothing but swap it in is the basic shape.

5.1. Hand-Writing lock()/unlock() Is Forbidden

Code that calls std::mutex’s lock() / unlock() directly ends up failing to release the lock on exceptions or early returns. Always leave lock acquisition and release to an RAII wrapper.

When there are two or more locks, having the acquisition order swap depending on the thread is the classic deadlock pattern (the circular wait in Figure 2 is born exactly this way). The fix is to make a rule that “every thread acquires locks in the same order”, but when you’re acquiring them at the same time, C++ has a better answer: hand several mutexes to std::scoped_lock together and the library guarantees deadlock-free acquisition order for you.⁴ In situations like a transfer between two objects where you want “both locked”, never take them individually — always take them together.

void Transfer(Account& from, Account& to, int amount)
{
    if (&from == &to) return;                  // do nothing for the same account (see note below)
    std::scoped_lock lock(from.mtx, to.mtx);   // both together; the library resolves the order
    from.balance -= amount;
    to.balance   += amount;
}

The identity check at the top is not decorative. If the same Account is passed as both from and to, you end up passing the same non-recursive mutex to scoped_lock twice, which causes a hang or undefined behaviour. Always attach a same-object exclusion to any function that “locks both”.

For data that is “read often, written rarely”, you can use std::shared_mutex (C++17) as a read/write lock.¹² recursive_mutex is a type designed so that “the same thread re-acquiring it doesn’t break”, but a design that needs recursive acquisition is often a sign that a lock’s responsibility boundary has become blurred — consider revisiting the structure first.

5.2. The Correct Role of atomic

std::atomic provides atomic operations on a single variable, plus ordering based on memory_order.⁵ It earns its place in the same situations as Interlocked in the .NET edition: updating a single variable, such as a counter or flag. It cannot keep several variables consistent together, so for that you fall back to std::mutex.

Swapping a raw pointer (std::atomic<T*>) has a trap all its own. Even though the swap itself is atomic, nobody protects the old object’s lifetime once it has been replaced. If a reader loads the old pointer just before the writer swaps it out and deletes it, you get an access to freed memory. If you want to do a “swap and share an immutable object” design in C++, choose a means that comes paired with lifetime management — swapping a lock-protected std::shared_ptr<const T>, or C++20’s std::atomic<std::shared_ptr<T>>.

And to repeat: volatile is not a thread-synchronisation tool. Lock-free programming where you specify memory_order yourself is expert territory, requiring both a legitimate reason to relax it from the default (seq_cst) and a way to verify that you’ve done so correctly. In business applications, either use the default or just write it with mutex in the first place.

6. Designing How to Stop — stop_token and Cooperative Stopping

The first question to ask when reviewing a multithreaded design is “how does this stop?” And C++ has no means of safely stopping a thread from outside (just how dangerous Win32’s TerminateThread is gets covered in detail in the C Edition). So how a thread stops has to be built with C++’s tools around cooperative stopping — the stopping side only issues a request; the thread itself decides when and how to end, at a point that leaves things tidy; and completion of the join is what counts as “stopped”.

In C++20, std::jthread has the stopping mechanism built in. Calling request_stop() raises the stop request on the std::stop_token that the thread function received, and the loop polls it. condition_variable_any’s wait can take a stop_token directly, so a “thread waiting for work to arrive” can also be woken instantly by a stop request (Section 4’s BlockingQueue::Pop takes exactly this shape).

class Worker {
public:
    void Start()
    {
        if (thread_.joinable())                       // Reject a double Start while already running.
            throw std::logic_error("already running"); // If we assigned instead of rejecting, a new
                                                       // thread would start running, and while it waits
                                                       // for the old thread to stop, two workers would
                                                       // end up running side by side
        thread_ = std::jthread([this](std::stop_token st) {
            try {
                while (!st.stop_requested()) {
                    if (auto item = queue_.Pop(st)) {   // wakes on a stop request too
                        try {
                            Process(*item, st);          // pass st into work that can block internally too
                        } catch (...) {
                            ReportError(std::current_exception());  // log a single failure and keep going
                        }
                    }
                }
            } catch (...) {
                // The last line of defence at the thread boundary (also catches failures
                // in Pop or a move). If an exception escapes from here, std::terminate takes
                // the whole process down, so make sure ReportError itself never throws
                ReportError(std::current_exception());
            }
        });
    }
    // No explicit Stop is needed:
    // Worker's destructor -> jthread's destructor -> request_stop() + join()
private:
    BlockingQueue<WorkItem> queue_{100};   // capacity-capped (Section 4)
    std::jthread thread_;
};

flowchart TB
    OWNER["The stopping side<br/>- jthread's destructor, or request_stop"] -->|"stop request"| ST["stop_token"]
    ST --> P["Compute loop:<br/>polls stop_requested()"]
    ST --> W["Waiting thread:<br/>condition_variable_any::wait(lock, st, pred)<br/>wakes immediately"]
    P --> E["Cleans up and returns on its own"]
    W --> E
    E --> J["join completes the rendezvous<br/>only now can we call it stopped"]

Figure 4: C++20 cooperative stopping. The stopping side only issues the request; the thread itself decides how it ends; completion of the join is what counts as stopped

One more point: the try/catch inside the worker cannot be omitted. What jthread makes exception-safe is the join, and only the join — if an exception escapes the thread function, std::terminate brings the process down, just as with std::thread. Decide explicitly, at the thread boundary, how to handle the failure of a single piece of work (log it and carry on, or report it to the owner over an error channel).

For the same reason, notice that Process is also passed the stop_token. If processing a single piece of work blocks internally (waiting on the network, a long computation, and so on) and that point cannot observe the stop request, the destructor’s implicit join will wait forever for that one item to finish. Cooperative stopping only holds together once the token has reached every place that waits. If the work includes an external call that cannot be interrupted, attach a timeout and put an upper bound on how long a single item is allowed to run.

In environments predating C++17, you build the same shape by hand with a std::atomic<bool> stop flag plus condition_variable’s notify_all. The key point here is to fold the stop-flag check into the condition variable’s predicate — if you just raise the flag and forget to notify, a waiting thread will never wake up.

7. Windows-Specific Concerns — the Boundary With the Win32 API

7.1. Choosing Between the Standard Library and Win32 Synchronisation Objects

Microsoft’s documentation recommends std::mutex / std::shared_mutex for C++ code that prioritises portability, and lays out Win32 synchronisation objects’ place as “when a Win32 wait API is needed” and “cross-process synchronisation”.⁸

For the concrete design of excluding access to shared memory across processes, see “Shared Memory Pitfalls and Practical Best Practices”.

7.2. Don’t Touch Threads Inside DllMain

A serious constraint when writing a DLL is the loader lock. DllMain is called while the loader lock is held, so operations inside it such as synchronising with another thread, waiting for a thread to end, or calling LoadLibrary cause deadlocks or unpredictable behaviour. Move any initialisation that starts or joins threads outside DllMain, into an explicit initialisation function.¹³

7.3. The UI Thread and COM Apartments

Windows desktop applications have a strong constraint that applies regardless of language: only the thread that created a window or control — the UI thread — may touch it. Windows delivers window messages to the message queue of the thread that created that window, so creating and manipulating the UI must be concentrated on that thread. When you want to update the screen from a worker thread, don’t touch it directly — ask the UI thread with PostMessage (asynchronous), and handle it in the window procedure on the UI thread’s side. Calling the synchronous form, SendMessage, while the UI thread is waiting for that worker to finish causes a deadlock where each waits on the other, so make the asynchronous form the default for notifications from a worker. STA/MTA, where COM is involved, is covered in “COM STA/MTA Fundamentals”. Also note that in C++/CLI code compiled with /clr, the standard thread headers such as <thread> and <mutex> are blocked.¹⁴

8. Verification and Debugging — Preparing on the Assumption It Won’t Reproduce

You cannot rely on testing to find race bugs, because an ordinary test counts a run that “happened not to race” as a pass. Think of the preparation in three layers.

The first line of defence is the design principles covered so far, exactly as they are. In review, confirm with a table: which mutable data is shared, which mutex protects each piece, whether the acquisition order of multiple locks is unique (or they’re taken together with scoped_lock), and where the stop path is. A design for which you cannot write this table is not finished, however well it currently runs.

Second, make abnormal states observable instead of hiding them. Attach a timeout with timed_mutex’s try_lock_for or condition_variable’s wait_for to any lock that ought never to fail to be acquired, and log a timeout as an anomaly — that turns an eternal hang into a detectable failure. Always log exceptions caught at the thread boundary’s try/catch (Section 6). When a hang or crash occurs in the field, capture a dump, check every thread’s stack, and look for whether their lock waits form a cycle. Setting up dumps and logging is covered in “Designing Logging and Dump Capture for Windows App Crashes”.

Third, shake things loose under load. Running for a long time with more parallelism than you have cores, randomising processing order, and injecting artificial delays are practical stress-testing techniques that make it easier to hit a race “jackpot” on a development machine. Bugs that disappear in a debug build often reproduce readily in an optimised release build under heavy load.

9. Summary — the C++ Checklist

Layer C++-specific checks on top of the principles common to every language: don’t create threads directly, minimise shared mutable state, a one-to-one correspondence between locks and data, and cooperative stopping.

1. Is std::thread being used bare (could it be a jthread? Is join guaranteed even on the exception path?)
2. Is detach() not being used?
3. Are lambda captures explicit, and does any reference-captured variable outlive the thread?
4. Can you say with confidence that there is not a single unsynchronised shared mutable access (= undefined behaviour) anywhere?
5. Is there no hand-written lock() / unlock(), and are multiple locks taken together with scoped_lock?
6. Is every condition_variable::wait used with a predicate?
7. Is volatile not being used for a shared flag (is it std::atomic instead)?
8. Is the stop path designed around stop_token (or an atomic flag plus notification), with completion of the join confirming the rendezvous?
9. Is the future from std::async not being discarded?
10. Is DllMain free of starting, synchronising, or joining threads?

Multithreaded C++ is work done walking right alongside the cliff edge of undefined behaviour, but turn that around and it means that simply going along honestly with RAII and the standard library’s conventions puts real distance between you and that edge. jthread, scoped_lock, predicate-form wait, atomic — choosing the right defaults among these tools is, in C++, the practice of the design principles itself.

Related Articles

• Practical Multithreading Best Practices: .NET Edition — What to Decide Before You Add More Threads
• Practical Multithreading Best Practices: C Edition — Writing Safely the Win32 API Way
• Practical Multithreading Best Practices: Java Edition — Conventions for the Virtual Thread Era
• Calling Native DLLs from C#: C++/CLI Wrapper vs P/Invoke
• Shared Memory Pitfalls and Practical Best Practices
• COM STA/MTA Fundamentals - Threading Models and How to Avoid Hangs
• The Depths of Windows I/O (Part 2) — Synchronous and Asynchronous I/O: What OVERLAPPED Really Means

Related Consulting Areas

KomuraSoft LLC handles multithread design reviews for C++ applications and DLLs, root-cause investigation (dump analysis) of race-condition bugs such as “crashes occasionally” or “only misbehaves in release builds”, and consulting on migrating legacy threaded code to modern C++.

• Technical Consulting & Design Review
• Bug Investigation & Root-Cause Analysis
• Windows Application Development
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

How should I choose between std::mutex and Win32's CRITICAL_SECTION / SRW locks?

For ordinary C++ code that prioritises portability, std::mutex / std::shared_mutex together with RAII wrappers (lock_guard / scoped_lock) are the first choice. Reach for Win32 synchronisation objects when you need to combine them with a Win32 wait API such as WaitForMultipleObjects, or when you need cross-process synchronisation through a named object. If you're using the Win32 API directly within a process, the default for new code is an SRW lock, and you use CRITICAL_SECTION only when the same thread needs to acquire it recursively. Using a Win32 Mutex for intra-process exclusion is a classic mistake, since it always involves a kernel transition and is correspondingly slow.

Is it okay to use std::thread's detach()?

As a rule, avoid it. A detached thread loses any means of being joined, and you lose control over whether it is still running when the process exits. It's a classic accident: a detached thread keeps running after static variables or the heap have been destroyed, and causes a shutdown crash. Being able to wait for a thread to finish is a basic requirement of thread design, so use jthread (which joins automatically), or, if you're using thread, structure the code to always join before the scope ends. detach is permissible only in the narrow situation where the thread can share the process's fate and you can guarantee it never touches shared state at all.

Can volatile be used for synchronisation between threads in C++?

No. C++'s volatile is a qualifier for reads and writes you don't want the compiler to optimise away — memory-mapped I/O, for example — and it does not guarantee visibility or ordering between threads. If multiple threads access the same variable without synchronisation, that is a data race, and it is undefined behaviour. Use std::atomic for flags and counters shared between threads, and std::mutex when you need to protect several variables together. std::atomic provides both atomicity of the operation and ordering based on memory_order.

std::async looks convenient, but are there any pitfalls?

The biggest pitfall is the future's destructor. The future (or the last shared_future) tied to a task launched with std::async blocks until completion if its destructor runs while the task is still incomplete. If you discard the returned future without holding onto it, that becomes equivalent to synchronous execution right there — an accident where you meant to go asynchronous but ended up serial. Also, when you don't specify a launch policy, whether the work actually runs on a separate thread is left to the implementation's discretion. If you use it, manage the future's lifetime explicitly, and specify std::launch::async wherever you need to guarantee concurrent execution.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.