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

[Carlo Wood <carlo at alinoe dot com>]

On Sat, Sep 29, 2001 at 02:23:21AM -0300, Alexandre Oliva wrote:
> On Sep 29, 2001, Carlo Wood <carlo@alinoe.com> wrote:
> > Imho, the optimal case would be where std::string is always one and
> > the same _type_.
> 
> I'd rather have instantiations of both thread-unsafe and thread-safe
> (when appropriate) versions of string in libstdc++.  This would
> probably solve the problem.  Ditto for allocators, if appropriate.

That is not true.  In this case it is perfectly logical to use allow
conversions between thread-safe and thread-unsafe string types.

Implicit conversion between the two can only be a problem in threaded
applications --> the end-application must be threaded otherwise there
will be no problem --> the end-application machine will support
threads and use a thread-safe std::string (or else there will be no
problem to begin with).

Then, if a shared library that one links with was compiled with a
compiler with threading support - there is no problem (also then
std::string is the thread-safe type).

So, the only problem that could *possibly* occur is when the shared
library was compiled with a compiler that does not support threads
(in which case the library is not thread-safe and *intended* for
single threaded applications).  Again, when the end-application is
single threaded, there is no problem with implicit conversion.

Last case that could possibly lead to a problem therefore is:

1) The shared library is (known to be) thread-unsafe and compiled
   with a compiler that uses a thread-unsafe std::string.
2) The end-application uses threads and is using a thread-safe
   std::string.
3) The user wants to pass a std::string that is used concurrently
   by multiple threads to a thread unsafe library function of
   the thread-unsafe shared library.  In that case he should
   provide locking HIMSELF, actually.

So apparently we take all these incompatibility disadvantages for
the cases:

A) single threaded library compiled with thread-safe compiler
   + single threaded application compiled with thread-unsafe compiler.
B) single threaded library compiled with thread-unsafe compiler
   + single threaded application compiled with thread-safe compiler.
C) multi threaded library compiled with thread-safe compiler
   + single threaded application compiled with thread-unsafe compiler.

to protect the stupid user in the case

D) single threaded library compiled with thread-unsafe compiler
   + multi threaded application compiled with thread-safe compiler.
   (where actually the user just needs to provide his own locking).

I really think that it was a wrong decision to include
thread-safeness in the mangling of std::string.

-- 
Carlo Wood <carlo@alinoe.com>