stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 18 Sep 2012 23:38:20 GMT
On 9/18/12 7:04 PM, Stefan Teleman wrote:
> On Tue, Sep 18, 2012 at 6:42 PM, Liviu Nicoara <> wrote:
>> The first check is indeed an optimization. It is the point of this exercise
>> to show that the unguarded reads in the localization library are not defects
>> and the code, simplified in my test case, is thread safe in exactly the
>> respects I mentioned before: the program only observes consistent, correct
>> values (program states) in a concurrent environment.
> The Intel Thread Analyzer shows a data race in the exact same spot the
> SunPro Thread Analyzer shows a data race, and in the exact same spot I
> have stated earlier that there is a data race.
> The results are available here:
> As usual, it is an Intel Inspector XE 2003 Analysis Results Blob. It
> opens with the Intel Inspector. i don't know what format it is in, or
> whether or not it can be read by other means.
> So far we have SunPro 12.3/Linux/Intel, SunPro 12.3/Solaris/Intel,
> SunPro 12.3/Solaris/SPARC and Intel 2003/Linux/Intel saying that there
> is a race condition in your program.
> And now I would like to get back to solving the thread-unsafety and
> race conditions problems in Apache stdcxx.

Stefan, you cannot ignore others' arguments and embrace a 'no' attitude; the 
tools are not saying what you think they do. They all show the same thing 
because they all do the exact same analysis and we could delve into that, too. I 
sincerely hoped you could come up with some sort of a logical argument that 
would prove my latest test case wrong, or at least show it failing at runtime.

My time is also limited and I have already spent more time than I wanted to 
trying to present a logical argument, down to the simplest test cases. I say we 
defer this to Martin for when he will be back from vacation, next week. For the 
record, because people may not have the energy to read all this back and forth, 
I will summarize here the gist of this thread:

1. The facet data caching is not MT-safe
2. The facet data initialization (STDCXX or system locales) is safe (*)
3. There is no unit test currently showing a failure in (2)
4. Timing results show that caching may be slower than non-caching in MT builds
5. A fix should, ideally, be binary compatible
6. A fix should, ideally, preserve performance or increase it
7. There is one patch, currently attached to the issue, by Stefan
8. Other partial patches are referenced from this thread

Please correct me if I missed anything. The above summary is a good starting 
point for a new thread dealing with this issue.



(*) When perfectly forwarding, with a theoretical concern I asked in an earlier 
post, directed at Martin.

View raw message