Re: [boost] Strings and thread safety (was: [lexical_cast] optimization commited to HEAD)

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-03 12:39:42

Corrado Zoccolo wrote:
> Hello,
> It just occurred to me that the thread safety problems with
> std::string are caused by the fact that the library is trying to
> decode the user intention from what methods he calls, instead of
> letting him declare it, and check at compile time that he is complying
> with the declared intention.

This may be the resulting reason, but the primary reason is that that the C++ 
std lib isn't designed to be threadsafe.  Getting back to lexical cast for a 
moment, as I think I said somewhere in the thread, string is not your only 
problem std::stringstream is your not thread safe either....so whatever gets 
done in this thread we won't be making lexical_cast threadsafe until you fix 
iostreams...

> I'm thinking to a solution in which the user has the choice of an
> immutable string, that behaves much like a ref counted "const char *"
> (or a String in java), and a mutable string as Java's StringBuilder.
> Something similar has been proposed also during the discussion on
> SuperString, and now it founds a further motivation for thread safety
> reasons.
>
 > For performance reasons (that is involved here, otherwise a basic deep
 > copy implementation would suffice to solve all problems), I think a
 > third usage type can be added: temporary strings, that are used to
 > mimic move semantics, until they are introduced into the language.

I guess.  I have to say that after doing some pretty heavy string coding in 
Java I personally don't like having to think about the distinction between the 
'builder' and the 'string'.  Perhaps I'm just brainwashed to the C++ way, but 
it's nice to just write std::string and not worry about if the code I write 
tomorrow will be modifying it.  Having to mess with another type is clunky and 
requires refactoring previous thinking.  But, I do understand the reasons and 
respect that some programmers prefer this approach.  So far the performance 
tests I wrote during the super_string discussion don't give a compelling edge 
to boost const_string -- it could just be a problem with the implementation, 
but at the moment it mostly loses to std::string.

> Now some sketched code, to explain better what I mean (I leaved out a
> lot of details as templated charT, charTraits and allocator):
> 
> <snip details>

Maybe a usage example of this code would be useful in understanding?  I guess 
the point is that since there is no mutating operator[] on imm_string it means 
that all query operations are threadsafe?

> This scheme addresses the performance problems noted in
> http://www.sgi.com/tech/stl/string_discussion.html for reference
> counted strings with unshareable state (like the g++ implementation),
> because now shareable/unshareable state is assigned by the user at
> compile time, and can be explicitly changed. In this way the user will
> know what to expect from the performance point of view, and the
> semantics will be (to my eyes) more clear.

This seems like a reasonable approach for those that want to go the immutable 
route....care to develop it into a full blown proposal?

Jeff