Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is a string property itself threadsafe?

String's in C# are immutable and threadsafe. But what when you have a public getter property? Like this:

public String SampleProperty{     get;     private set; } 

If we have two threads and the first is calling 'get' and the second is calling 'set' at the "same" time, what will happen?

IMHO the set must made a lock to be thread-safe like this:

private string sampleField; private object threadSafer = new object();  public String SampleProperty{     get{ return this.sampleField; }     private set{         lock(threadSafer){             sampleField = value;         }     }  } 
like image 531
TomTom Avatar asked Jan 12 '09 09:01

TomTom


People also ask

What does being Threadsafe mean?

In the simplest of terms threadsafe means that it is safe to be accessed from multiple threads. When you are using multiple threads in a program and they are each attempting to access a common data structure or location in memory several bad things can happen.

What does Threadsafe mean in Java?

When multiple threads are working on the same data, and the value of our data is changing, that scenario is not thread-safe and we will get inconsistent results. When a thread is already working on an object and preventing another thread on working on the same object, this process is called Thread-Safety.

Are strings thread-safe C#?

This is thread-safe without any need for locking. Strings are reference types, so only a reference to the string is being modified.

Are String objects thread-safe?

Operations on String objects are thread-safe. (They are thread safe because String objects are immutable, but the why is not directly relevant to your example.) Unsynchronized read and write operations1 on non- final shared2 variables are not thread-safe, irrespective of the type of the variable.


1 Answers

Most of the answers are using the word "atomic" as if atomic changes are all that are needed. They're not, usually.

This has been mentioned in the comments, but not usually in the answers - that's the only reason for me providing this answer. (The point about locking at a coarser granularity, to allow things like appending, is entirely valid as well.)

Usually you want a reading thread to see the latest value of the variable/property. That isn't guaranteed by atomicity. As a quick example, here's a bad way to stop a thread:

class BackgroundTaskDemo {     private bool stopping = false;      static void Main()     {         BackgroundTaskDemo demo = new BackgroundTaskDemo();         new Thread(demo.DoWork).Start();         Thread.Sleep(5000);         demo.stopping = true;     }      static void DoWork()     {          while (!stopping)          {                // Do something here          }     } } 

DoWork may well loop forever, despite the write to the boolean variable being atomic - there's nothing to stop the JIT from caching the value of stopping in DoWork. To fix this, you either need to lock, make the variable volatile or use an explicit memory barrier. This all applies to string properties as well.

like image 180
Jon Skeet Avatar answered Sep 21 '22 11:09

Jon Skeet