Re: libstdc++ and race detectors

[Kostya Serebryany <kcc at google dot com>]

On Tue, Jul 13, 2010 at 4:28 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>> Hi Paolo,
>>
>> On Fri, Jul 9, 2010 at 4:22 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>>
>>> On 07/09/2010 01:29 PM, Kostya Serebryany wrote:
>>>
>>>> Before we proceed with a bug report or a patch file, we'd like to know
>>>> your opinion on the problem.
>>>>
>>>>
>>> I don't know if you are aware of that, but in the forthcoming, so-called
>>> C++0x, standard reference counting implementations of basic_string will
>>> be ruled out.
>>>
>> Good!
>> Will the library have any other code with atomic synchronization?
>>
> Yes, just grep...

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).
Would you please suggest how to run multi-threaded tests for the new library?

>> I prepared a draft of this change: http://codereview.appspot.com/1800042 .
> Please post any tentative change here, inline.
>> Unfortunately, this change required to add ?__attribute__
>> ((always_inline)) to _M_dispose and ~basic_string. I am not sure this
>> is acceptable.
>> Without ?__attribute__ ((always_inline)) ?the approach doesn't work
>> because ~basic_string does not get inlined and we call the version of
>> ~basic_string from libstdc++.so, which does not have the annotations.
>> Any suggestion?
>>
> 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.

> 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.

Anyway, how soon do you expect the new code to replace the current one?

Thanks,

--kcc


>
> Paolo.
>
>