On 9/18/12 7:04 PM, Stefan Teleman wrote:
On Tue, Sep 18, 2012 at 6:42 PM, Liviu Nicoara <[email protected]> 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:
http://s247136804.onlinehome.us/liviu-mt-test/22.mt.test.r000ti3.inspxez
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.
HTH.
Liviu
(*) When perfectly forwarding, with a theoretical concern I asked in an earlier
post, directed at Martin.
