thread-safe strings

[Martin v. Loewis]

> 	I've looked over the code for basic_string a bit and see that there
> is a problem with _M_state being accessed from multiple threads. Are
> there other problems that I'm missing here? If not couldn't we just
> put a mutex on _M_state?

I think there is a number of problems with it. First, you don't know
readily what thread system you are using, and whether it has a mutex
operation - libstdc++ should also support systems using something else
than pthreads, as well as systems without threads.

Next, putting the thread operations into the header file means that
C++ applications always have to link with the threads library, even if
they woudn't use it otherwise. If possible, it should be an
application decision to use threads or not. Conditional compilation
helps, but also has the risk of introducing binary incompatibilities -
eg. if the layout of a string object silently changes depending on
whether threads are used or not, then you'll risk a lot of user
complaints about 'random' crashes.

Finally (and probably most important), mutex operations are expensive
- especially if the application is not multithreaded. You want *at
least* some two-phase magic, where you eliminate cases that don't
require locking (e.g. if the string is guaranteed not to be shared).

> Also, how can I verify that string is thread-safe after mucking
> around with it? a test case?

I don't think so. You'll have to verify this kind of stuff by
inspection.

Regards,
Martin