Subj : Re: Is std::cerr thread safe
To   : comp.programming.threads
From : Sean Kelly
Date : Wed Jul 20 2005 03:46 pm

Maciej Sobczak wrote:
> Sean Kelly wrote:
>
> > The STL is guaranteed to be thread-safe
>
> No, it isn't (and cerr is not STL).
>
> It is rather considered to be a Quality of Implementation issue (you
> will not find it in the standard) that the program at least does not
> crash when I/O is accessed in a MT way.

I actually meant that the guarantee is merely that standard library
components will compile and operate in a multithreaded environment,
though I admit that this seems fairly self-apparent.  In my experience,
this mostly means that mutable global statics are either not used or
that access to them is serialized.  Is this also a QOI issue?  I'll
admit I haven't read the standard very closely in this regard.

> > std::ostringstream ostr;
> > ostr << "error: " << errno << '\n';
> > std::cerr << ostr.rdbuf();
>
> Even if cerr has this Quality of Implementation guarantee, I would not
> bet my money that it is at the level which would be appropriate above.
> Try with *very* long messages (to overflow any potential buffer on the
> road) to see where the synchronization is in your particular library
> implementation.

True enough.  My point was merely that the above method might work in a
limited manner, not that I'd suggest deploying applications that use
the method :)  I've used this method once or twice for temporary debug
code, as it was faster to write than the alternatives.  And as you say,
this is very implementation dependent.


Sean

.