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

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

[ljrittle]

Synopsis: Regression: iostreams no longer threadsafe

State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Mon Mar 24 22:05:03 2003
State-Changed-Why:
    In terms of there being a change in behavior, your observation is correct.  However, we consider the new behavior to be in line with our published guidelines on application requirements to obtain correct thread safety.  In sum, all library objects  which are visibly shared across threads need to have application-level locking to obtain thread safety.
    After reading the discussion on this topic in the library documentation,
    please report your agreement or disagreement with this change.
    FYI, this behavior has been stable since FSF gcc 3.0 was released.
    Another FYI, in this particular case, the primary problem is that we don't know where interleaving of method calls on the global objects should be allowed or disallowed.  Only the application really knows.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10193

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

[Pétur Runólfsson]

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

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

[peturr02]

>Number:         10193
>Category:       libstdc++
>Synopsis:       Regression: iostreams no longer threadsafe
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 23 19:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     peturr02@ru.is
>Release:        gcc-3.2.2
>Organization:
>Environment:
Red Hat Linux 8.0
>Description:
The iostreams implementation in gcc-2.95.x was reasonably threadsafe, as is stdio on glibc-2.3. The implementation of iostreams in gcc-3.x is however not threadsafe at all.
>How-To-Repeat:
See attachment.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="threadbug.cc"
Content-Disposition: inline; filename="threadbug.cc"

#include <iostream>
#include <sstream>
#include <vector>
#include <cstdlib>

#include <unistd.h>
#include <pthread.h>

void* thread(void* p)
{
	using namespace std;
	int n = *static_cast<int*>(p);

	for (;;)
	{
		ostringstream stream;
		stream << "thread" << n << '\n';
		clog << stream.str();
	}

	return 0;
}

struct threadstuff
{
	pthread_t t;
	int n;
};

int main(int argc, char** argv)
{
	using namespace std;

	int numthreads = 10;
	if (argc > 1)
		numthreads = atoi(argv[1]);

	vector<threadstuff> vec (numthreads);

	pthread_attr_t attr;
	pthread_attr_init(&attr);

	for (int i = 0; i < numthreads; ++i)
	{
		vec[i].n = i;
		pthread_create(&vec[i].t, &attr, &thread, &vec[i].n);
	}

	sleep(10);
	return 0;
}