On 09/21/12 05:13, Stefan Teleman wrote:
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
<travis.vi...@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.


Reply via email to