It's simple: since standard C++ currently doesn't even acknowledge the existence of threads, the standard makes no mention of them whatsoever, nor of thread safety issues. The thread safety of components is therefore completely up to the implementation.
Apparently MS's implementation is thread-safe (or as thread-safe as the shared-state cout can possibly be), while GCC's is not.
But if a thread obtains a lock on the Mutex associated with IO (locking before it uses cout, and unlocking afterwards) which is a shared resource, then the code becomes thread safe, correct?
Originally Posted by pheres
That's sort of the point. For a library function/object to be thread safe, it would need to function correctly even if the code using it does not protect access to it. cout is not thread safe so, if it is to be used from multiple threads, it must be protected.
Originally Posted by indigo0086
It is often very difficult (sometimes impossible) for a library function or object (which is logically represented by a set of interacting functions that share some data) to protect itself against access from multiple threads. So the responsibility for serialising access falls on the code which uses it.