Thread safety of cout

[Paolo Carlini]

Nathan Myers wrote:

>On Fri, Oct 08, 2004 at 01:43:19AM +0200, Paolo Carlini wrote:
>  
>
>>Something that I still don't grasp completely is the difference between
>>fwrite / fwrite_unlocked and fflush / fflush_unlocked: the (glibc (*))
>>specs don't seem to imply that the first two, respectively, take a 
>>lock?!? In that case, I would exclude at least pregnancy... ;)
>>    
>>
>Probably the POSIX people who (rashly) chose to ihave putc() and getc() 
>take a lock by default felt that special optimized versions of fwrite() 
>and fflush() were not necessary, because they would not be called 
>frequently enough for the locking overhead to matter.  I would imagine 
>further that the glibc people added the "_unlocked" versions for 
>what they thought of as completeness.
>  
>
I see. 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?

Paolo.