std::cout 是线程安全的，但会导致竞争条件吗？

Question

I'm looking at an online course for C++ multithreading, and I see the following:

If std::cout can have race conditions, then how is it that it's thread-safe? Isn't thread-safety, by definition, free of race conditions?

Answer 1

It's distinguishing between the ordering of calls to operator<< and outputting of each character as a result of those calls.

Specifically, there is no conflict between threads on a per-character basis but, if you have two threads output pax and diablo respectively, you may end up with any of (amongst others):

paxdiablo
diablopax
pdaixablo
padiablox
diapaxblo

What you quoted text is stating is that there will be no intermixing of the output of (for example) p and d that would cause a data race.

And a race condition isn't necessarily a problem, nor a thread-safety issue, it just means the behaviour can vary based on ordering. It can become such an issue if the arbitrary ordering can corrupt data in some way but that's not the case here (unless you consider badly formatted output to be corrupt).

---

It's similar to the statement:

result = a * 7 + b * 4;

ISO C++ doesn't actually mandate the order in which a * 7 or b * 4 is evaluated so you could consider that a race condition (it's quite plausible, though unlikely, that the individual calculations could be handed off to separate CPUs for parallelism), but in no way is that going to be a problem.

---

Interestingly, ISO C++ makes no mention of race conditions (which may become a problem), only of data races (which are almost certainly a problem).

Answer 2

There are many levels of thread safety. Some programs must complete in exactly the same order every time. They must be as-if they were executed in a single thread. Others permit some level of flexibility in the order in which statements are executed. The spec's statements about std::cout state that it is in the latter category. The order that characters will be printed to the screen is unspecified.

You can see the two behaviors in the act of compiling. In most cases, we don't care about the order that things get compiled in. We happily type make -j8 and have 8 threads (processes) compiling on parallel. Whatever thread does the work is fine by us. On the other hand, consider the compiling requirements of NixOS . In that distro, you compile every application yourself and cross-check it against hashes posted by the authors. When compiling on NixOS, within a compilation unit (one.c or.cpp), you absolutely must operate as-if there is a single thread because you need the exact same product deterministically -- every time.

There is a darker version of this kind of race behavior known as a "data race." This is when two writers try to write the same variable at the same time, or a reader tries to read it while a writer tries to write to it, all without any synchronization. This is undefined behavior. Indeed, one of my favorite pages on programming goes painstakingly through all the things that can go wrong if there is a data rate.

So what is the spec saying about needing to lock cout? What it's saying is that the interthread behavior is specified, and that there is no data race. Thus, you do not need to guard the output stream.

Typically, if you find you want to guard it, it's a good time to take a step back and evaluate your choices. Sure, you can put a mutex on your usage of cout , but you can't put it on any libraries that you are using, so you'll still have issues with interleaving if they print anything. It may be a good time to look at your output system. You may want to start passing messages to a centralized pool (protected by a mutex), and have one thread that writes them out to the screen.

Answer 3

The text is there to warn you that building some thing entirely out of "thread-safe" components does not guarantee that the thing you built will be "thread-safe."

The std::cout stream is called "thread-safe" because using it in multiple threads without any other synchronization will not break any of its underlying mechanism. The cout stream will behave in predictable, reasonable ways; Everything that various threads write will appear in the output, nothing will appear that wasn't written by some thread, everything written by any one thread will appear in the same order that the one thread wrote it, etc. Also, it won't throw unexpected exceptions, or segfault your program, or overwrite random variables.

But, if your program allows several threads to "race" to write std::cout , there is nothing that the authors of the library could do to help predict which thread will win. If you expect to see data written by several threads appear in some particular order, then it's your responsibility to ensure that the threads call the library in that same order.

Don't forget that a statement like this is not one std::cout function call; it's three separate calls.

std::cout << "there are " << number_of_doodles << " doodles here.\n";

If some other thread concurrently executes this statement (also three calls):

std::cout << "I like " << name_of_favorite_pet << ".\n";

Then the output of the six separate std::cout calls could be interleaved, eg:

I like there are 5 fido doodles here.
.