incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Travis Vitek <Travis.Vi...@roguewave.com>
Subject RE: STDCXX-1056 : numpunct fix
Date Fri, 21 Sep 2012 06:28:04 GMT

> -----Original Message-----
> From: Stefan Teleman
> Sent: Thursday, September 20, 2012 6:00 PM
> To: dev@stdcxx.apache.org
> Cc: Liviu Nicoara
> Subject: Re: STDCXX-1056 : numpunct fix
> 
> On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström"
> <cbergstrom@pathscale.com> wrote:
> 
> 
> I do have a program which triggers the race conditions:
> 22.locale.numpunct.mt. Part of the "official" test harness.
>

I don't think anyone is claiming that there isn't a thread safety problem in the locales.
I'm open to the possibility, and I'm willing to review changes that fix the problem, but I
want some understanding of what the problem actually is and how the changes actually address
the problem before signing off.

I also find it hard to believe the changes to the facet cache (and many of the other changes)
are necessary to eliminate any data races that were reported by these tools. Changing the
cache size from 8 to 64 is _clearly_ not going to fix a data race. It might reduce the likelihood
of one occurring, but it isn't going to fix it. I also fail to understand how not reducing
the size of the cache fixes a data race either. These changes all appear to be optimizations,
and as such, should _not_ be included in changes to fix thread-safety issues.

Perhaps we could go about this a different way. Test your code without the changes to the
facet cache changes in _C_manage and report back on what you find. Or, perhaps more simply,
provide minimal diffs (as required by the patching process) to fix the data race issues that
you've outlined.
 
> The real reason why they don't want to accept what the instrumentation
> tools are saying is very simple: they don't LIKE reading what the
> tools are saying. So, blame the tools, pretend that "as long as it
> doesn't crash again there's no bug" and hope for the best.

My previous e-mail attempted to indicate that I don't trust the output that these tools have
provided. I have no understanding of how the tool managed to find a data race in __rw_allocate
(or _C_manage). Do you? Doesn't this output give you some doubt about the accuracy of the
tool?

I have no problem using a tool to make my job easier. Sometimes those tools are wrong. The
two cases mentioned above call into question the accuracy of the tool being used, and it is
important to understand why those failures are being seen (or why I am wrong about the given
code being safe).

> But I am very glad this is on a public mailing list, so everyone can
> read what's going on here.

As am I.

I've raised concerns about the tools you're using to detect problems. I've pointed out what
I believe to be two false positives, and you've accused me of being incompetent and afraid
of what the tools are saying. You've offered no explanation about these apparent false positives
and you've not provided any explanation for why you don't see similar false positives when
you run the code on the patched library.

I've raised concerns about some of the changes you've provided being unnecessary to resolve
the issue at hand (a thread safety issue) and labeled them as optimizations (your original
e-mail seemed to indicate you were under the same impression). As Liviu pointed out, the bug
fix changes should be handled separately from the optimization. I wholeheartedly agree.

You called out premature optimization as evil, in a discussion about patches you provided
that include optimizations and no testcase showing that your changes are not premature and
provide measureable benefit. Then you rail on...

Then, to top it off, you go on to call me a know-it-all who isn't capable of figuring out
my own bugs.

I'm sorry, but that isn't acceptable.

Travis

Mime
View raw message