> -----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"
> <cbergst...@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.


Reply via email to