Is cout synchronized/thread-safe?

In general I assume that streams are not synchronized, it is up to the user to do appropriate locking. However, do things like cout get special treatment in the standard library?

That is, if multiple threads are writing to cout can they corrupt the cout object? I understand that even if synchronized you'd still get randomly interleaved output, but is that interleaving guaranteed. That is, is it safe to use cout from multiple threads?

Is this vendor dependent? What does gcc do?

---

Important: Please provide some kind of reference for your answer if you say "yes" since I need some kind of proof of this.

My concern is also not about the underlying system calls, those are fine, but the streams add a layer of buffering on top.

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.

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.

> 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: https://stackoverflow.com/questions/1483403/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.

As other answers mention, this is definitely vendor-specific since the C++ standard makes no mention of threading (this changes in C++0x).

GCC doesn't make a whole lot of promises about thread safety and I/O. But the documentation for what it does promise is here:

• http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html#manual.intro.using.concurrency.io

the key stuff is probably:

> The __basic_file type is simply a > collection of small wrappers around > the C stdio layer (again, see the link > under Structure). We do no locking > ourselves, but simply pass through to > calls to fopen, fwrite, and so forth. > > So, for 3.0, the question of "is > multithreading safe for I/O" must be > answered with, "is your platform's C > library threadsafe for I/O?" Some are > by default, some are not; many offer > multiple implementations of the C > library with varying tradeoffs of > threadsafety and efficiency. You, the > programmer, are always required to > take care with multiple threads. > > (As an example, the POSIX standard > requires that C stdio FILE* operations > are atomic. POSIX-conforming C > libraries (e.g, on Solaris and > GNU/Linux) have an internal mutex to > serialize operations on FILE*s. > However, you still need to not do > stupid things like calling fclose(fs) > in one thread followed by an access of > fs in another.) > > So, if your platform's C library is > threadsafe, then your fstream I/O > operations will be threadsafe at the > lowest level. For higher-level > operations, such as manipulating the > data contained in the stream > formatting classes (e.g., setting up > callbacks inside an std::ofstream), > you need to guard such accesses like > any other critical shared resource.

I don't know if anything has changed sine the 3.0 timeframe mentioned.

MSVC's thread safety documentation for iostreams can be found here: http://msdn.microsoft.com/en-us/library/c9ceah3b.aspx:

> A single object is thread safe for > reading from multiple threads. For > example, given an object A, it is safe > to read A from thread 1 and from > thread 2 simultaneously. > > If a single object is being written to > by one thread, then all reads and > writes to that object on the same or > other threads must be protected. For > example, given an object A, if thread > 1 is writing to A, then thread 2 must > be prevented from reading from or > writing to A. > > It is safe to read and write to one > instance of a type even if another > thread is reading or writing to a > different instance of the same type. > For example, given objects A and B of > the same type, it is safe if A is > being written in thread 1 and B is > being read in thread 2. > > ... > > iostream Classes > > The iostream classes follow the same > rules as the other classes, with one > exception. It is safe to write to an > object from multiple threads. For > example, thread 1 can write to cout at > the same time as thread 2. However, > this can result in the output from the > two threads being intermixed. > > Note: Reading from a stream buffer is > not considered to be a read operation. > It should be considered as a write > operation, because this changes the > state of the class.

Note that that information is for the most recent version of MSVC (currently for VS 2010/MSVC 10/cl.exe 16.x). You can select the information for older versions of MSVC using a dropdown control on the page (and the information is different for older versions).