RE: libstdc++/10193: Regression: iostreams no longer threadsafe

["Pétur Runólfsson" <peturr02@ru.is>]

The following reply was made to PR libstdc++/10193; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: <ljrittle@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	=?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: libstdc++/10193: Regression: iostreams no longer threadsafe
Date: Fri, 25 Apr 2003 22:27:05 -0000

 I apologise for taking so long to reply to this.
 
 >     In terms of there being a change in behavior, your=20
 > observation is correct.  However, we consider the new=20
 > behavior to be in line with our published guidelines on=20
 > application requirements to obtain correct thread safety.  In=20
 > sum, all library objects  which are visibly shared across=20
 > threads need to have application-level locking to obtain=20
 > thread safety.
 >     After reading the discussion on this topic in the library=20
 > documentation,
 >     please report your agreement or disagreement with this change.
 
 There seem to be two main points in the documentation that apply
 here:
 
 1) That the application can easily provide locking, so the library
    doesn't need to do so.
 
 2) That adequate locking can't be provided by the library.
 
 I agree with point 1), except for the global objects cout, cerr
 etc. It seems implied that library code that's intended to be
 thread-safe can't touch these objects and that multi-threaded
 programs can't use third-party libraries that may use these
 objects.
 
 Point 2) seems implied by the statement
 >  you might not think of an I/O stream as a container, but
 >  the points made there also hold here.
 I don't agree with this: The most basic reason
 containers can't be made thread-safe is that they return
 references to internal data structures, but I/O operations
 return by value. I also disagree with this because thread-safe
 iostreams implementations exist (most notably gcc-2.95); using
 such an implementation without external locking may be somewhat
 tricky, but is in many cases possible.
 
 Petur