incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1056 : numpunct fix
Date Fri, 21 Sep 2012 13:10:15 GMT
On 09/21/12 05:13, Stefan Teleman wrote:
> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
> <Travis.Vitek@roguewave.com> wrote:
>
> I have provided this list with test results showing that my patch
> *does* fix the race condition problems identified by all the tools at
> my disposal. I'm willing to bet you never looked at it. You dismissed
> it outright, just because you didn't like the *idea* that increasing
> the size of the cache, and eliminating that useless cache resizing
> would play an important role in eliminating the race conditions.


I looked at it in great detail and I am sure Travis read it too. The facet/locale buffer management
is a red herring. Apparently, we cannot convince you, regardless of the argument. That's fine
by me.


>
> I have yet to see an alternative patch being proposed here, which
> would eliminate the race conditions, and which I am willing to test
> just as thoroughly as I've tested mine. The only thing i've seen are
> continued attempts at dismissing the existence of these race
> conditions, as  reported by the instrumentation tools, based on some
> general axioms about their accuracy. No-one on this list has a clue as
> to how the SunPro Thread Analyzer actually works, because it's not
> open source, and none of you work at Oracle, therefore you can't see
> the code. But everyone just *knows* that it's inaccurate, or that it
> reports false positives.

We are not dismissing the analysis. We are dismissing your interpretation of it. The tool
is not indicating a defect, but a potential defect. I am calling it potential because, as
my test case (http://tinyurl.com/97ks9gc) indicates, one can have a race condition which is
not a defect in a concurrent environment.

>
> As long as you, or anyone else, continues to blame the instrumentation
> tools for the bug, and as long as anyone here continues to suggest
> that the only acceptable proof of the existence of this bug is some
> other program which needs to be written using fprintf(3C), and as long
> as no-one here is willing to provide an alternative patch which
> demonstrably eliminates 100% of the reported race conditions, this
> entire back-and-forth about the existence of these race conditions,
> the accuracy of the tools and what they are reporting is nothing but a
> giant waste of time.
>

The correction of 1056 does not necessarily need to eliminate the analyzer warnings. Aiming
for that is simply unreasonable, not because it is not attainable (after all, you demonstrated
it), but because it is inappropriately and insufficiently argued for the situation at hand.

Liviu

Mime
View raw message