stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: Intel Thread Checker Support
Date Tue, 29 May 2007 19:58:26 GMT
Liviu Nicoara wrote:
> Liviu Nicoara wrote:
>> Liviu Nicoara wrote:
>>> On May 21, 2007, at 7:17 PM, Martin Sebor wrote:
>>>
>>>> Liviu Nicoara wrote:
>>>>> I agree it would be a spectacular demonstration of the usefulness 
>>>>> of the tool but -- based on my knowledge of the stdcxx code -- I 
>>>>> strongly doubt I can demonstrate an MT bug in it. Do you know of an 
>>>>> unresolved MT bug in stdcxx?
>>>>
>>>> There is a problem in locale (as usual, sigh :( A couple of our
>>>> thread safety tests have been crashing: 22_mt and 22_time_put_mt.
>>
>> I see they are not ported to the new infrastructure yet. Are they 
>> failing in dev or latest release? One [looong] run of 22_mt yielded no 
>> failures.
> 
> FWIW, the run of the 4.1.4-rel branch of locale/mt.cpp (in a 15s build 
> on Linux Slackware 10.2 on x86, with Intel 9.1.042) has yielded the 
> analysis in the attached file. I have chosen the text format and a width 
> of 140 columns for readability. Please notice that the run has not 
> failed any [test] assertions.
> 
> I am not sure what to make about the errors flagged by the ITC tool 
> because I am not sufficiently familiar with the locale code. A quick 
> glance over the places in the analysis report shows unguarded rw 
> accesses  to certain memory locations (used to store facets?). I am not 
> sure though whether this access is intentionally unguarded or not.

They do look unguarded but I don't think I would describe
them as bugs given the "loose" rules for thread safety we
follow in stdcxx (we make assumptions about ordering and
visibility that aren't guaranteed to hold in general but
typically do in our experience). OTOH, for something as
involved and as "lightly" used as locale we should probably
err on the side of safety and avoid making them altogether.
Certainly, we would need to clean up (or silence) all these
errors in order for the the Thread Checker reports to be
useful to stdcxx users. Otherwise they wouldn't be able to
reliably tell whether the errors represent potential thread
safety issues in their programs or not even after they
cleaned up all errors coming out of their own code. I think
this cleanup would be useful for us to do but the hard part
will be running the Thread Checker on all our thread safety
tests and analyzing the results. And since we don't even
have tests for all our thread-safety sensitive code we'd
also need to add some. They wouldn't be too difficult to
write. I'd say we should be able to add tests for all of
locale in a week, and then take another week to clean up
all the errors.

Martin

Mime
View raw message