This is the mail archive of the
mailing list for the libstdc++ project.
Re: Thread safety clarification
[Get raw message]
Benjamin Kosnik wrote:
>Hmm. I missed the whole "November will be threading questions" email.
Yep - I saw all the other threading questions, and figured I would chip
in my own 2 cents :-)
>>The reason for my concern is that I have a program which breaks after a
>>period of load compiled with gcc 3.0.1 with a non-optimized release on
>>Solaris (x86 and sparc) but not under Linux x86 - with an optimized
>>build on Linux, the program breaks invariably on startup.
>linux -O0 +
>linux -O2 -
>solaris -O0 -
>solaris -O2 -
>I'm assuming these toolchains are all configured with
>--enable-threads=posix? What's an "optimized build?" What is the lowest
>level of optimization that will trigger the error? Does turning off some
>optimizations allow the binary to execute correctly? See the gcc online
>docs for what opts are turned on at which optimization level, and flags
>that allow fine-tuning (ie turn off specific optimizations.)
All have posix threads enabled, an optimized build is -O2.
I will do some more experimentation tonight to find out which concrete
option(s) cause problems.
>>2.95.2 and its STL I don't have these problems (or rather; string's
>>reference counting bug breaks me before the issue comes up),
>Ok. So this never worked with g++?
Well, with the old STL (v2), I always got hit by the refcounting on the
global empty string not being threadsafe. Testing this with the current
problem, I always hit this before I got hit with anything else. I also
didn't have the problems with optimizations, but I understand that
2.95.2 and 3.0.2 are substantially different under-the-hood.
My current problem looks like a race condition in v3, nine times out of
ten it has reported a problem related to strings, and I've seen memory
debugging tools like dmalloc writing over the data in constant global
strings (marking it off as deleted).
>>STLPort on 2.95.2 I have yet to have any problems other than extreme
>Okay. Let's try to get this fixed then. What opts are being used with
>Can you be a bit more specific? You're comparing a lot of stuff here.
Yep, it was more of a 'can someone tell me where to start' than a 'can
someone tell me what the problem is' - I'll grab more specifics tonight.
Right now it is two issues:
- breaking after a while do to some race condition, which appears to be
doing things like deleting globally defined std::string s.
- breaking nearly immediately and predictably when certain optimization
options are on.
>>Any clues to help get this whole thing solved?
>You'll need to post some source code that is self-contained, as small as
>possible, and allows others to reproduce the problem. Without this,
>helping you figure this out is pretty difficult. Look on the web
>archives of this list for the last month or so for some examples, and read that commentary.
Will do. Is there anything special I need to do to get debugging symbols
for optimized builds? I can try to track down the section of code where
it is breaking on the optimized builds. My problem right now is that it
is breaking rather randomly on debug builds, and there are substantial
difficulties in debugging threaded programs under Linux. I'm trying to
get something substantially smaller than 10k lines of code to illustrate
the problem, though. :-)