Re: Thread safety of cout

[Dan Evison <devison at pacificit dot co dot nz>]

> >>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!)

I know it's pot luck when writing to unprotected objects from multiple
threads, but it is surprising to me it doesn't blow up more repeatedly.  One
simple test I wrote with nine threads writing to cout, ran successfully for
many hours, creating over 10GB of cout output without problem. That is
10,000 times more output than my application which has deadlocked twice.
The test probably isn't doing exactly the same operations on cout, though I
tried to make them similar.

I have synchronized all access to cout in my application - if something else
is the cause of deadlock I'd better continue looking into it...