Thread safety and string

[Nathan Myers]

> 
> > "While parts of the SGI STL are used in libstdc++-v3, their string class
> > is not. The SGI string is essentially vector<char> and does not do any
> > reference counting like libstdc++-v3's does. (It is O(n), though.)
> > Contrary to what some say, reference counting is not incompatable with
> > multithreading, if done correctly"

The above is true, but describes design choices, not completed
implementation.
 
> Hmm. This is not as clear as it should be. I'm defining a thread-safe
> container as per the SGI STL definition, here:
> 
> http://www.sgi.com/Technology/STL/thread_safety.html
> 
> v-3's string implementation uses ref-counted strings, and is thought to be
> thread-safe. I would be interested in your experiences using it in such a
> matter. Nathan Myers, its principal author, may be able to offer more info
> and field more specific questions.

The v3 basic_string is designed to be easy to make thread-safe, given
locking primitives.  AFAIK those have not been contributed yet.  (They
would be different for each target architecture.)
 
> SGI STL 3.2 has another string implementation, which is also believed to
> be thread-safe. There is also the SGI STL rope container. 
> 
> So you have a lot of choices, all of which should be thread-safe.

The SGI STL has been written to be able to use locking if it is 
available.  With the absence of locking primitives, none of the 
library can be considered thread-safe.  

In summary, the library has been designed, and mostly coded, to be
thread-safe eventually, but is not yet.

Nathan Myers
ncm@cantrip.org