Re: Thread safety of cout

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Fri, Oct 08, 2004 at 10:10:30AM +0200, Paolo Carlini wrote:
> To recapitulate my point, since cin, cout & co. by default use
> now the new sync filebuf, which, in turn, only uses putc (/not/
> putc_unlocked), fwrite (/not/ fwrite_unlocked) and so on, I wouldn't
> expect big problems, actually...  Looking at the current glibc specs,
> it seems that not only getc and putc take locks, but also fwrite,
> fflush, etc., otherwise /why/ the *_unlocked counterparts?

This is not a Good Thing.  It's not something we should promise
to maintain in the future, by documenting it.  (Anyway now we have 
a report that maybe it doesn't work.)  It's not portable behavior,
so we don't do users any favors by encouraging them to depend on 
it.  Furthermore, I hope that we have aspirations to make the 
default cin and cout operations fast by default, someday.
Unrealistic promises could permanently forestall such an advance.
For now, probably we should use the _unlocked counterparts where 
present, so that there is no implicit promise.  

Am I correct in thinking that after one has called 
ios::sync_with_stdio(false), cout does not continue to use 
inherently slow operations?  Then user library code can't assume
that cout is thread-safe anyway.

I'd like to issue a warning ("cin and cout are very slow if 
ios::sync_with_stdio(false) is not called during program startup") 
if a program is linked without a hard reference to ios::sync_with_stdio.
Otherwise users might never know why their programs are unaccountably 
slow, or how to fix them.  Is there an easy way to get such a warning?
(I imagine a weak symbol, marked deprecated, in the same segment with
some initialization code, but overridden by the real sync_with_stdio.)

Nathan Myers
ncm@cantrip.org