Is std::cout Thread‑Safe? Understanding Data Races, Race Conditions, and Practical Solutions in C++

The article investigates the thread‑safety of std::cout in C++. It begins by clarifying the difference between a data race and a race condition, emphasizing that they are related but distinct concepts in concurrent programming.

Data Race & Race Condition

A data race occurs when two conflicting accesses to the same variable (at least one write) are not ordered by a happens‑before relationship, while a race condition refers to incorrect program behavior caused by nondeterministic execution order. The article illustrates these ideas with a simple lock‑protected example where two threads write to x under a mutex, guaranteeing atomicity but still leaving the final value of x nondeterministic.

Thread 1    Thread 2

 lock(l)      lock(l)
 x=1          x=2
 unlock(l)    unlock(l)

Because each write is protected, there is no data race, but the lack of a defined order creates a race condition.

Is std::cout Thread‑Safe?

Historically, before C++11, the standard made no guarantees about the thread‑safety of std::cout or any standard iostream. Concurrent writes could interleave, corrupting output. The article cites the C++11 standard (§27.4.1) which states that concurrent access to a synchronized iostream shall not cause a data race, though interleaved characters are still possible unless the programmer adds explicit synchronization.

Thus, from C++11 onward, std::cout does not cause memory corruption, but its output may still be mixed when multiple threads write simultaneously.

Typical Interleaved Output Example

Two threads write different messages to std::cout without synchronization. Because each insertion operator is evaluated separately, the characters can be interleaved, producing output such as:

Thread 1: The operation took Thread 2: Hello world! yule
10 seconds

The article breaks down the statements into individual operator<< calls to show how the ordering of buffer writes leads to the mixed result.

Solution Using std::mutex

One straightforward fix is to protect each thread’s output with a mutex, ensuring that only one thread writes to the buffer at a time.

std::mutex cout_mutex;

void thread1() {
    std::lock_guard<std::mutex> lock(cout_mutex);
    std::cout << "Thread 1: The operation took " << sec << " seconds
";
}

void thread2() {
    std::lock_guard<std::mutex> lock(cout_mutex);
    std::cout << "Thread 2: Hello world! " << name;
}

While effective, this approach adds locking overhead.

Alternative Wrapper Approaches

The article presents two wrapper techniques that also use a mutex internally: a PrintThread class derived from std::ostringstream that flushes its buffer in the destructor, and a static Cout utility that builds a temporary string buffer before a single std::cout call.

class PrintThread : public std::ostringstream {
public:
    ~PrintThread() {
        std::lock_guard<std::mutex> guard(_mutexPrint);
        std::cout << this->str();
    }
private:
    static std::mutex _mutexPrint;
};

Both wrappers serialize the entire message, preventing interleaving but still incurring mutex cost.

Ultimate Solution with C++20 std::osyncstream

C++20 introduces std::osyncstream (and std::basic_syncbuf) which automatically synchronizes output to a stream. Using it eliminates manual locks while guaranteeing that each thread’s output appears as an atomic block.

void thread1() {
    std::osyncstream sync_stream(std::cout);
    sync_stream << "Thread 1: The operation took " << sec << " seconds
";
}

void thread2() {
    std::osyncstream sync_stream(std::cout);
    sync_stream << "Thread 2: Hello world! " << name;
}

With std::osyncstream, the two threads produce non‑interleaved, readable output without explicit mutex management.