Re: [boost] Strings and thread safety

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-09-07 20:41:57

Gregory Dai wrote:
> On 9/3/06, Jeff Garland <jeff_at_[hidden]> wrote:
>> 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 can attest to your statement about std::stringstream, Jeff. We made both a
> string w/o reference counting and a stringstream that wraps up the string in
> the same way as std::stringstream does to std::string to get around the
> thread safety issue we have been discussing here. Perhaps there is more to
> std::stringstream in this regard, as I remember you talked about some global
> variables in it, but it appeared the issue stopped at replacing it with the
> customized stringstream (in addition to replacing std::string).

Well, I suppose you could replace std::stringstream with a custom one which is 
  sure to be threadsafe, but I'd bet all of the performance gain would be gone 
by the time you were done.

Anyway, my whole objection is to the 'claim' that 'thread safety in 
lexical_cast' had somehow been lost.  lexical_cast was NEVER thread safe to 
start -- not one word in the docs indicates that it is thread-safe, and the 
implementation clearly isn't because of several things that are used.  So 
clients using lexical_cast from multiple threads should beware...

Jeff