This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
RE: Re: libstdc++/10193: Regression: iostreams no longer threadsa fe
- From: "Futia, Anthony J" <anthony dot j dot futia at lmco dot com>
- To: "Futia, Anthony J" <anthony dot j dot futia at lmco dot com>, "'peturr02 at rus dot is'" <peturr02 at rus dot is>, "'gcc-bugs at gcc dot gnu dot org'" <gcc-bugs at gcc dot gnu dot org>, "'nobody at gcc dot gnu dot org'" <nobody at gcc dot gnu dot org>, "'gcc-prs at gcc dot gnu dot org'" <gcc-prs at gcc dot gnu dot org>
- Date: Mon, 21 Apr 2003 19:13:19 -0400
- Subject: RE: Re: libstdc++/10193: Regression: iostreams no longer threadsa fe
Could this be a link problem? Need to add the -pthread(s) flag
> -----Original Message-----
> From: Futia, Anthony J
> Sent: Monday, April 21, 2003 7:01 PM
> To: 'peturr02 at ru dot is, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org,
> gcc-prs at gcc dot gnu dot org'
> Subject: Re: libstdc++/10193: Regression: iostreams no longer
> threadsafe
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc
> &pr=10193
>
> If I read response to this problem correctly, the application is
> responsible for locking all constructors and method calls of the
> ostringstream class in its threaded application by some global mutex, even
> if the objects are not shared in anyway.
>
>
> However the sample application has no shared data except that which is
> underlying in the ostringstream class (assumption). If the assumption is
> true then why isn't the ostringstream class responsible for protecting its
> shared data.
>
>
> I am experiencing the same problem with the gcc implementation of the
> ostringstream class using only the ostringsteam constructor. Since I am
> using shared libraries, it is impossible for me to serialize all of the
> ostringstream methods and constructors.
>
>
>
>