stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <stefan.tele...@gmail.com>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 18 Sep 2012 23:04:22 GMT
On Tue, Sep 18, 2012 at 6:42 PM, Liviu Nicoara <nikkoara@hates.ms> 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

-- 
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com

Mime
View raw message