Re: Thread safety clarification

[David Waite <mass at akuma dot org>]

Benjamin Kosnik wrote:

>Hmm. I missed the whole "November will be threading questions" email. 
>Oh well.
>
>;)
>
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.
>>
>
>so:
>
>linux   -O0  +
>linux   -O2  -
>solaris -O0  -
>solaris -O2  -
>
Looks correct

>
>
>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.

>>Under gcc 
>>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).

>>and using 
>>STLPort on 2.95.2 I have yet to have any problems other than extreme 
>>slowness.
>>
>
>Okay. Let's try to get this fixed then. What opts are being used with 
>STLPort?
> 
>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.
>
>-benjamin
>
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. :-)

-David Waite