This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread safety of cout


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]