Question

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;         }     }  } 

Answer 1

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.