libstdc++/5037: Multithreaded read access to strings not threadsafe on Solaris/Sparc

[Loren James Rittle]

Hi Nathan,

Since you posted untested (it was dumb to even ask you in my first
e-mail of the morning ;-), I made the assumption that you wanted it
checked on sparc.

>> > I believe this file [libstdc++-v3/config/cpu/sparc/*/bits/atomicity.h]
>> > is broken.  __exchange_and_add and __atomic_add use separate locks,
>> > and so are not protected from each other.

>> Any best solution (in terms of contention) requires a locking word
>> related to the first argument.  Would a designer of the atomicity.h
>> abstraction layer prefer to provide such a solution?

> This code was extracted from glibc-2.0.  Maybe they have already
> fixed it there.  (If so, thanks a lot for the heads-up, guys.)

> Here's a diff (untested) that relies on traditional linker behavior
> to define the global object somewhere all by itself.

Results of compiling the short test case against your patch in, mine
out (I did fully rebuild libstdc++-v3 since dependencies are not
properly listed against atomicity.h):

; /usr/local/beta-gcc/bin/g++ -pthreads -R/usr/local/beta-gcc/lib bugger.cpp
/var/tmp/ccMpkBGq.o: In function `__exchange_and_add(int volatile*, int)':
/var/tmp/ccMpkBGq.o(.text+0x5c): undefined reference to `_S_atomicity_lock'
/var/tmp/ccMpkBGq.o(.text+0x60): undefined reference to `_S_atomicity_lock'
/var/tmp/ccMpkBGq.o(.text+0xa8): undefined reference to `_S_atomicity_lock'
/var/tmp/ccMpkBGq.o(.text+0xac): undefined reference to `_S_atomicity_lock'
/var/tmp/ccMpkBGq.o: In function `__atomic_add(int volatile*, int)':
/var/tmp/ccMpkBGq.o(.text+0xcc): undefined reference to `_S_atomicity_lock'
/var/tmp/ccMpkBGq.o(.text+0xd0): more undefined references to `_S_atomicity_lock' follow

Oh joy, taking off the 'extern' produces this during a full rebuild:

[...]/std_bitset.h:353: multiple definition of `_S_atomicity_lock'
[..many more similar lines...]

We could use the same trick used in STL C++ headers and put the lock
in a template which is always instantiated with the same argument.
Or, must this header be compilable by a plain-old C compiler?

> Somebody should look at the other atomicity.h files and see if there
> are any more of these. 

I have added doing such an audit to my gcc task list.