This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Thread safety of cout
Nathan Myers wrote:
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.)
The report itself is puzzling, you are 100% right and I mean to study it in
better detail (thanks Dan for the complete info!)
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.
Actually, are rather fast now, overall (many thanks to Pétur for this),
at least
when fwrite/fread are involved and the locking overhead is low.
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.
Indeed, I seem to remember that Pétur already envisaged this. We can do
that, I agree with you, if we all agree about the basic philosophy, it's
mostly
a matter of autoconf tests, otherwise trivial to implement.
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.
You are 100% correct, since read/write &co don't promise anything AFAIK.
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.)
I don't know... However, perhaps we should benchmark a little more: actually
the current sync_filebuf is rather fast and the last time I benchmarked,
normal
I/O was quite fast, even competitive with filebuf I/O in some cases: we
should
consider that fwrite/fread are locked but nevertheless use the buffering
layer
provided by stdio, by default... And, from the point of view of
correctness, we
*must* sync with stdio by default anyway.
Paolo.