Re: libstdc++ and race detectors

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 14 July 2010 13:54, Kostya Serebryany wrote:
>> You know, my idea would be, adding the macros for consistency
>> *everywhere* an atomic counter is decreased (I gather this is the
>> technical core of the problem). And then, in the docs, point out which
>> are effective (that is, able to actually suppress the warnings) with a
>> normally built library, which require the extern template trick on the
>> command line (I think only basic_string), which require a library
>> rebuild. I'm not saying you have to provide the whole package at once,
>> for instance you can split out the documentation work, but please commit
>> to something consistent for 4.6.x,
> Which is when?
> I do commit if there is enough time.

Stage 1 started in April, so I would be surprised if 4.6.0 is released
before next April, based on the timelines of recent releases:
http://gcc.gnu.org/develop.html#timeline

> A related question: does libstdc++ have other kinds of atomic
> synchronization (e.g. lock free queues, locks free hash maps, etc)?

There are no lock free containers in libstdc++.  We use atomics for
reference-counting in a few places that you already know (strings,
shared_ptr, locales, ios::Init) and also for exception handling in the
runtime, see libsupc++/eh_throw.cc and libsupc++/eh_ptr.cc (both of
these are exported in a .so and would need recompilation for
annotations to help.)

The C++0x thread features (<thread>, <mutex>, (condition_variable> and
<future>) are built from pthreads (or similar) primitives, so are not
a problem for race detectors.  The C++0x <atomic> header is only an
experimental implementation and is not used by the library. Programs
which make use of those features would need to add their own
annotations as required.

The profile mode and parallel mode use some atomic operations in
places, but I'm not sure exactly how they're used or what for. Not
reference counting AFAIK.