Re: libstdc++ and race detectors

[Paolo Carlini <paolo dot carlini at oracle dot com>]

On 07/13/2010 03:53 PM, Kostya Serebryany wrote:
> Ha!
> There seem to be plenty of atomics here an there; the question is if
> they are race-detector-hostile (we'll need to check).
>   
Please check, in any case we want a consistent solution.
> Would you please suggest how to run multi-threaded tests for the new library?
>   
We don't have any special framework for that. Of course the testsuite
already includes a set of multithreaded tests.
>> This is not happening by chance: user code *is* supposed to use for
>> basic_string instantiated for char and wchar_t the symbols exported by
>> the .so. Essentially, for basic_string, you have to make up your mind at
>> library build time. The only exception we have is debug-mode, where the
>> trick is that -D_GLIBCXX_DEBUG essentially disables extern template (ie,
>> _GLIBCXX_EXTERN_TEMPLATE is -1 for debug-mode, see c++config).
>>     
> _GLIBCXX_DEBUG is not a choice, I afraid.
> This mode contains so much extra code (various expensive run-time
> checks) -- it will add additional slowdown to race detectors, which
> are already slow.
>   
You didn't get my point: it was about setting _GLIBCXX_EXTERN_TEMPLATE =
-1 for your things, like debug-mode does.
>> I would
>> suggest experimenting with that, as a last resort. Actually, I would
>> rather prefer trying to get in first a version of your change as clean
>> as possible, not using that trick, because we are already touching code
>> I would rather not touch at this stage, and anyway for other bits of the
>> library using reference counting and exported from the .so the trick is
>> not available anyway, because no templates are involved.
>>     
> If ~basic_string has to remain in .so, I don't see any way to
> implement annotations w/o performance loss. :(
> For now I afraid we will have to suppress reports with ~basic_string in stack...
> Julian, Bart, Frank, if you think otherwise, please speak up.
>   
But see the above. If, after a careful audit of the various uses of
atomic operations in the library you come up with a proposal to set
_GLIBCXX_EXTERN_TEMPLATE = -1 also for this new case, and document it, I
think that would be acceptable, in principle. Of course a precondition
is that *nothing* changes by default, when the user isn't measuring
anything.
> Anyway, how soon do you expect the new code to replace the current one?
>   
You mean when the completely new implementation of basic_string will
replace the current one? Frankly I don't know, it's a delicate change,
will happen when we'll break the ABI.

Paolo.