Re: Problem with `string', threading and shared libraries.

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <flu1xi33kt.fsf@jambon.cmla.ens-cachan.fr>,
Gabriel Dos Reis <gdr@codesourcery.com> writes:

> | He had compiled libstdc++ with a macro, reserved to the
> | implementation, defined and then he compiled his user code without
> | that macro defined.  Nowhere do we document that macro being used by
> | normal users of the library.  

> Thanks for the clarification.  I guess I need to clarify my position
> as well: I don't think --enable-threads should change std::string
> mangled name. 

OK, I think it works the way you desire.  The rest of this e-mail
serves as a public record, not really directed at Gabriel --- whom I
know could do the same analysis of the current situation himself.

We must consider 6 cases.  All of these cases assume that no user
monkeyed in our implementation macro space as per ISO C99 section
7.1.3 (e.g. compiled some code with _NOTHREADS and some without; or
compiled some code with __USE_MALLOC and some without).  We do not
consider any cases where two compilers are used; one configured with
--enable-threads=X and the other with --enable-threads=Y where X != Y
(I certainly have no practical experience with that situation since
few ports support more than one legal value for the thread package).

1. All C++ code compiled by gcc 3.X configured with --enable-threads.
   The final program is actually single-threaded.

Works, as expected.  Once we started using the gcc/gthr.h abstraction
layer under libstdc++ V3: On some platforms, the speed is almost equal
to that of a compiler which was configured with --disable-threads due
to the use of weak symbols (or other per-platform tricks).

2. All C++ code compiled by gcc 3.X configured with --enable-threads.
   The final program is multi-threaded.

As long as ``gcc -v'' reported a thread model other than none: Works,
as expected.

3. All C++ code compiled by gcc 3.X configured with --disable-threads.
   The final program is single-threaded.

Works, as expected.

4. All C++ code compiled by gcc 3.X configured with --disable-threads.
   The final program is actually multi-threaded.

Undetectably broken.  It might work, or it might not, on any
particular run.  The most basic problem is that C++ exception handling
will not work properly.  Up the stack from there, standard C++ library
resources might get trashed.

It is hard to conceive of any test which would portably check for this
situation even under ideal conditions.

5. Without declaring how libstdc++ itself was built, some C++ code
   compiled by gcc 3.X configured with --enable-threads and some C++
   code compiled by gcc 3.X configured with --disable-threads.  The
   final program is single-threaded.

This is a key case we are concerned about.  There are a couple of
reasonable ways to go (maximum flexibility on what may be legally
linked together verses extra error checking).  Here is the current
design: All this code is ABI-link compatible and implementation-logic
compatible.  Some unnecessary mutex locking occurs on some platforms
for some of the code but it will work properly when linked with the
other code since none of the locking was actually required for
correctness when the final program is single-threaded.  In all cases
(due to compilation-unit layout), the lock implementation is always
properly paired to the required unlock implementation.

6. Without declaring how libstdc++ itself was built, some C++ code
   compiled by gcc 3.X configured with --enable-threads and some C++
   code compiled by gcc 3.X configured with --disable-threads.  The
   final program is multi-threaded.

In general, under the current design: Undetectably broken, for similar
reasons listed in 4.  It would be possible to make this situation
link-time detectable at the expense of weakened compatibility of case
5.  I.e. all cases that would have been compatible are turned into
link-time failures as well.

Although the root issues are the same as 4, there are perhaps
additional issues and opportunities to discuss here which would
improve robustness over the shipped gcc 3.0: Although the linkage is
ABI-link compatible, it is not entirely implementation-logic
compatible since for threading to work, all must agree to use the same
mutexes and protocols.  Would it be possible to force
implementation-logic compatibility?  Under the current design, no.  Is
it possible across all the implementations of the current gcc/gthr.h
abstraction layer (while possibly allowing for changes to that
abstraction layer as required)?  No one has presented a mechanism to
do that yet, at least in a manner that would replace all the uses of
the abstraction layer in the STL code.  People have tried...

Regards,
Loren