stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <mse...@gmail.com>
Subject Re: STDCXX-1056 : numpunct fix
Date Tue, 25 Sep 2012 02:03:12 GMT
FWIW, there are race conditions in stdcxx. Some of them are by
design and benign on the systems the library runs on (although
I acknowledge that some others may be bugs). One such benign
date race is:

   time    T1      T2
     0    x = N
     1    x = N   read x

where x is a scalar that can be accessed atomically by the CPU
and the compiler.

I think some of the lazy facet initialization falls under this
class. It would be nice to fix them but only if it doesn't slow
things down. The others need to be fixed in any case.

Martin

On 09/20/2012 06:11 PM, Stefan Teleman wrote:
> On Thu, Sep 20, 2012 at 8:04 PM, Wojciech Meyer
> <wojciech.meyer@googlemail.com>  wrote:
>
>
>> Therefore please use tools but be a bit reserved for the results.
>
> I *am* being cautiously skeptical about the results. That's why I am
> using 4 [ FOUR ] different thread analyzers, on three different
> operating systems, each one of them in 32- and 64- bit, and not just
> one.
>
> With this testing setup described above, when all FOUR instrumentation
> toosl report the same exact problem in the same exact spot, for all
> flavors of the operating system, what would be a rational conclusion?
>
> 1. There is indeed a race condition and thread safety problem, it
> needs to be investigated and fixed..
>
> 2. Bah, the tools are crap, nothing to see here, move along, declare victory.
>
> I chose [1] because I am willing to accept my *own* limitations.
>


Mime
View raw message