Is cout synchronized/thread-safe?

Solution 1:

The C++03 standard does not say anything about it. When you have no guarantees about the thread-safety of something, you should treat it as not thread-safe.

Of particular interest here is the fact that cout is buffered. Even if the calls to write (or whatever it is that accomplishes that effect in that particular implementation) are guaranteed to be mutually exclusive, the buffer might be shared by the different threads. This will quickly lead to corruption of the internal state of the stream.

And even if access to the buffer is guaranteed to be thread-safe, what do you think will happen in this code?

// in one thread
cout << "The operation took " << result << " seconds.";

// in another thread
cout << "Hello world! Hello " << name << "!";

You probably want each line here to act in mutual exclusion. But how can an implementation guarantee that?

In C++11, we do have some guarantees. The FDIS says the following in §27.4.1 [iostream.objects.overview]:

Concurrent access to a synchronized (§27.5.3.4) standard iostream object’s formatted and unformatted input (§27.7.2.1) and output (§27.7.3.1) functions or a standard C stream by multiple threads shall not result in a data race (§1.10). [ Note: Users must still synchronize concurrent use of these objects and streams by multiple threads if they wish to avoid interleaved characters. — end note ]

So, you won't get corrupted streams, but you still need to synchronize them manually if you don't want the output to be garbage.

Solution 2:

This is a great question.

First, C++98/C++03 has no concept of "thread". So in that world, the question is meaningless.

What about C++0x? See Martinho's answer (which I admit surprised me).

How about specific implementations pre-C++0x? Well, for example, here is the source code for basic_streambuf<...>:sputc from GCC 4.5.2 ("streambuf" header):

 int_type
 sputc(char_type __c)
 {
   int_type __ret;
   if (__builtin_expect(this->pptr() < this->epptr(), true)) {
       *this->pptr() = __c;
        this->pbump(1);
        __ret = traits_type::to_int_type(__c);
      }
    else
        __ret = this->overflow(traits_type::to_int_type(__c));
    return __ret;
 }

Clearly, this performs no locking. And neither does xsputn. And this is definitely the type of streambuf that cout uses.

As far as I can tell, libstdc++ performs no locking around any of the stream operations. And I would not expect any, as that would be slow.

So with this implementation, obviously it is possible for two threads' output to corrupt each other (not just interleave).

Could this code corrupt the data structure itself? The answer depends on the possible interactions of these functions; e.g., what happens if one thread tries to flush the buffer while another tries to call xsputn or whatever. It might depend on how your compiler and CPU decide to reorder memory loads and stores; it would take a careful analysis to be sure. It also depends what your CPU does if two threads try to modify the same location concurrently.

In other words, even if it happens to work fine in your current environment, it might break when you update any of your runtime, compiler, or CPU.

Executive summary: "I wouldn't". Build a logging class that does proper locking, or move to C++0x.

As a weak alternative, you could set cout to unbuffered. It is likely (although not guaranteed) that would skip all logic related to the buffer and call write directly. Although that might be prohibitively slow.

Solution 3:

The C++ Standard does not specify whether writing to streams is thread-safe, but usually it's not.

www.techrepublic.com/article/use-stl-streams-for-easy-c-plus-plus-thread-safe-logging

and also: Are standard output streams in C++ thread-safe (cout, cerr, clog)?

UPDATE

Please have a look at @Martinho Fernandes' answer to know about what the new standard C++11 tells about this.