On Thu, Dec 3, 2009 at 5:46 PM, David Levin <levin@chromium.org> wrote:
On Thu, Dec 3, 2009 at 5:21 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
Handling strings on multiple threads is driving me crazy.

My recommendation don't use strings on multiple threads. If you do, it has a high chance of being wrong because it is very subtle so try not to do it.

Instead creating a string for another thread is using crossThreadString which is relatively cheap (sorry about the name, I have a bug on fixing that just haven't had time to think of something better). (Note that method isn't threadsafe.)
 

For example, String1 + String2 is not safe if either of those threads is from another thread (since if either string is empty, it'll just point to the other strings StringImpl).

See above : don't do it :)
 
 Another example: if you have a class that isn't always destroyed on the same thread and anything is making a copy of a string it owns

Don't hand out strings from such a class. Only hand out strings that come from the crossThreadString method or the copy method. Or only give out a UChar*.

(Of course, it would be nice if you could make your class always be destroyed on the same thread or at least destroy all of its strings on the same thread where they were used.)

Easier said than done in many cases.  For DOM Storage and Databases, there are several classes that are used on multiple threads.  And several of these classes contain strings (or contain things that contain strings).  It seems very difficult to be absolutely sure these strings are only shared in a safe way unless you make a threadsafeCopy every time you access it.  Doing so would probably be negligible performance wise for all the cases I'm looking at, so maybe that's the right answer, but these issues are very subtle.  And that's what concerns me most.
 
I understand that making all strings ThreadSafeShared is completely out of the question, but maybe we can make another class of strings that is safe?  Maybe we can even do it in a way that still shares the majority of the existing string code?  (Ideally without resorting to templates.)

Or is there a way to change your code to not use the same string class on multiple threads?

A big issue is the RefCounted base for StringImpl. (Next you'd also have problems with append, insert, etc.)

Exactly....so we couldn't use StringImpl as is.  We could, however, wrap all access to methods that could ref it and/or mutate it with a lock (as an example).

I just don't want to have to keep thinking about the subtle threading issues of strings in cases where there's no way it could be performance critical.