Re: Access form objects from a class - C# Discussion Boards

13-Jun-06 11:05

Hello,

Is it necessary to ensure thread-safety for an instance of the System.String class? I understand that Strings are immutable types, but I was unsure if this necessarily means that an instance of the System.String class is thread-safe for multiple readers and multiple writers.

In my application, several Strings which belong to an instance of a class will be both accessed and changed from multiple threads. I can easily put a lock on them and make sure the operations do not clash, but if I do not have to waste time waiting for the lock because the type is naturally thread-safe then of course I do not want to.

I understand that this may be a simple question, but for some reason I cannot find a clear universal answer to the question.

Thanks in advance!

Sincerely,
Alexander Wiseman

User 665813-Jun-06 11:17

User 6658

13-Jun-06 11:17

They are not threadsafe by default. Only static variables are automatically threadsafe.

regards

modified 12-Sep-18 21:01pm.

Alexander Wiseman13-Jun-06 11:28

13-Jun-06 11:28

Thanks for your reply. I am still confused, however, because in the MSDN documentation, it says this about a System.String (and it makes no distinction between static members and instance members):

Quote from MSDN System.String Overview

Thread Safety
This type is safe for multithreaded operations.

End quote from MSDN

Furthermore, just because a variable is declared to be static does not mean that it is thread safe. I was under the impression that the programmer had to make sure that variables, even static ones, were thread safe.

That being said, my original confusion remains, because it seems like, from the MSDN documentation, there is nothing required on the part of the user of the System.String class to ensure thread safety. What little I have read concerning "immutability" of the string type would support this. On the other hand, if I am doing multiple write operations and multiple read operations, is there going to be a problem?

Thanks again.

Sincerely,
Alexander Wiseman

Leslie Sanford13-Jun-06 11:40

Re: System.String and Thread Safety [modified]

13-Jun-06 11:40

Alexander Wiseman wrote:
That being said, my original confusion remains, because it seems like, from the MSDN documentation, there is nothing required on the part of the user of the System.String class to ensure thread safety. What little I have read concerning "immutability" of the string type would support this. On the other hand, if I am doing multiple write operations and multiple read operations, is there going to be a problem?

Since strings are immutable, they are thread safe. What happens when you perform a write operation on a string is that a new string is created as a result; the original string remains unchanged.

Alexander Wiseman13-Jun-06 11:46

Re: System.String and Thread Safety [modified]

13-Jun-06 11:46

Thanks for your reply.

Let me just make sure I have this clear with a quick example. Let us say that I have two threads, A and B, both of which have access to String someStr = "My String".

Now let's say that the processor gives a time-slice to thread A, which then reads the string. Then the processor gives a time-slice to thread B, which then changes the string from "My String" to "Your String".

If I understand you correctly, then because strings are immutable, no matter when the processor decides to temporarily stop processing on thread A, nevertheless thread A will still see the value "My String", even though thread B may have "changed" it already. Is that correct?

Thanks again for your help!

Sincerely,
Alexander Wiseman

-- modified at 17:48 Tuesday 13th June, 2006

[EDIT]

Just read another poster's reply, which answers this scenario in the affirmative.

[/EDIT]

Leslie Sanford13-Jun-06 11:58

Re: System.String and Thread Safety [modified]

13-Jun-06 11:58

Alexander Wiseman wrote:
Let me just make sure I have this clear with a quick example. Let us say that I have two threads, A and B, both of which have access to String someStr = "My String".

Now let's say that the processor gives a time-slice to thread A, which then reads the string. Then the processor gives a time-slice to thread B, which then changes the string from "My String" to "Your String".

If I understand you correctly, then because strings are immutable, no matter when the processor decides to temporarily stop processing on thread A, nevertheless thread A will still see the value "My String", even though thread B may have "changed" it already. Is that correct?

What you're doing here isn't changing the string. You are changing the reference to the string. When you do this:

string someString = "My String";

And then do this:

someString = "Your String";

You've taken the reference to "My String" and changed it to point (sorry for the C++ nomenclature) to "Your String";

That's not the same as actually changing the string. And as far as I know, changing what a reference, erm, references is not an intrinsically thread safe operation, but I could be wrong.

Changing the actual string would be doing something like this:

string someString = "My String";

// Just making this method up for the example.
someString.Concatenate(" and Your String");

// Output: "My String and Your String"
Console.WriteLine(someString);

Now, the above code isn't possible with an immutable string. Rather the operation for concatenating a string creates a new string:

string someString = "My String";

string anotherString = someString.Concatenate(" and Your String");

// Output: My String"
Console.WriteLine(someString);
// Output: My String and Your String"
Console.WriteLine(anotherString);

Again, I'm not sure if the string class actually has a "Concatenate" method, but the principle is the same. When doing a write operation on a string, a new string is created as a result leaving the original unchanged.

[EDIT]Apparently, changing what an object references is an atomic operation, so it is thread safe.[/EDIT]

-- modified at 18:00 Tuesday 13th June, 2006

Leslie Sanford13-Jun-06 11:44

13-Jun-06 11:44

Alexander Wiseman wrote:
In my application, several Strings which belong to an instance of a class will be both accessed and changed from multiple threads. I can easily put a lock on them and make sure the operations do not clash, but if I do not have to waste time waiting for the lock because the type is naturally thread-safe then of course I do not want to.

When you say that the strings belong to an instance of a class and are accessed and changed, are you talking about string properties?

-- modified at 17:44 Tuesday 13th June, 2006

Alexander Wiseman13-Jun-06 11:52

13-Jun-06 11:52

Thanks for your help, Leslie. Actually I think the question was simpler than that - Guffa's post below answers it.

Sincerely,
Alexander Wiseman

Guffa13-Jun-06 11:46

Guffa

13-Jun-06 11:46

As strings are immutable, you can't change a string. What happens when you assign a new value to a string variable, is that the new value is a separate string object, and the reference to that object replaces the reference to the previous value.

As reading and writing references are atomic, there is no need to use a lock.

When you read the string value, you are copying the reference to the string. You can then use that reference to access the string that was the value at the moment you read the reference, without fear of anything happening to that string.

---
b { font-weight: normal; }

Alexander Wiseman13-Jun-06 11:51

13-Jun-06 11:51

Thanks for your reply Guffa. That makes perfect sense! I think the thing that I was missing was that reading and writing references are atomic.

Sincerely,
Alexander Wiseman

Leslie Sanford13-Jun-06 12:00

13-Jun-06 12:00

Guffa wrote:
As reading and writing references are atomic, there is no need to use a lock.

Oh, that's good to know! I had guessed that it wasn't but glad to learn that I was wrong.

Mr. VB.NET13-Jun-06 12:46

Mr. VB.NET

13-Jun-06 12:46

The original post was correct strings are immutable and therefore threadsafe.

Judah Gabriel Himango13-Jun-06 13:24

Judah Gabriel Himango

13-Jun-06 13:24

It's kind of misleading though. For instance:

if(someVolatileVariable != null)
{
   someVolatileVariable.DoSomething(); // Buggy! (in a multithreaded environement, anyways)
}

That is buggy multithreaded code! The reason is that another thread could potentially set someVolatileVariable to null after the current thread checks whether it is not null. A correct version of that would be:

Foo someVar = someVolatileVariable;
if(someVar != null)
{
   someVar.DoSomething();
}

Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Goof around music jam with my brothers (with video)
The apostle Paul, modernly speaking: Epistles of Paul

Judah Himango

Leslie Sanford13-Jun-06 13:36

13-Jun-06 13:36

Good point. Events work the same way:

Bad:

if(WorkCompleted != null)
{
    WorkCompleted(this, EventArgs.Empty);
}

Good:

EventHandler handler = WorkCompleted;

if(handler != null)
{
    handler(this, EventArgs.Empty);
}