On 8/31/06, John Maddock <john@johnmaddock.co.uk> wrote:
Caleb Epstein wrote:
On 8/31/06, John Maddock <john@johnmaddock.co.uk> wrote:
In any case all the implementations I'm aware of are minimally thread safe these days, if that's not the case I'd certainly like to hear about it. BTW implementations that used copy-on-write in the early days almost all (all?) switched away from that precisely because of threading issues.
Even the latest libstdc++ (GNU's Standard C++ library) uses a refcounted std::string.
Darn, I hadn't realised that :-(
One needs to be careful when sharing strings across thread boundaries. See these bug reports for a detailed discussion:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10350 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
Very interesting stuff!
I'm not sure that it's relevent in this case though: if you're lexical_cast'ing *to* a string then these issues shouldn't arise, whether there are other threads getting involved or not. If you're casting *from* a string, then it appears that you need a mutex if you know the string is likely to be visible to other threads, even if all accesses to it are non-mutating.
Have I got that right?
Well, not completely perhaps. E.g., at least if the target is a std::string of size=0, the resultant std::string may well be reference-counted and shared by multiple threads. WRT std::string, the solution appears to be using a string implementation that does not use reference counting, as you rightly pointed out. The GCC folks can resolve the bugs reported against the GCC library by replacing their std::string implementation. In most cases, as we can use std::string w/o worrying about threading issues, we can do the same with lexical_cast as well. BTW, I like lexical_cast a lot! Thanks to this community for making it available. Thanks, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Thanks, Greg