title: Is locking access to a bool required or is it Overkill
body: <p>I have a class that is designed primarily as a POCO class, with various Threads and Tasks could read its values, and only others only occasionally updating these values. This seems to be an ideal scenario for ReaderWriterLockSlim.</p>
  
  <p>The question is, in the class, if the property that needs to be thread-safe, if the property is a bool, is that overkill? what happens if it is an int? DateTime?</p>
  
  <pre><code>public class MyClass
  {
    private bool _theValue = false;
    private ReaderWriterLockSlim _theValueLock = new ReaderWriterLockSlim();
  
    public bool TheValue
    {
      get
      {
        bool returnVal = false;
        try
        {
          _theValueLock.EnterReadLock();
          returnVal = _theValue;
        }
        finally
        { _theValueLock.ExitReadLock(); }
        return returnVal;
      }
      set
      {
        try
        {
          _theValueLock.EnterWriteLock();
          _theValue = value;
        }
        finally
        { _theValueLock.ExitWriteLock(); }
      }
    }
  }
  </code></pre>
  
  <p>Is all this code overkill, and a simple...</p>
  
  <pre><code>public bool TheValue { get; set; }
  </code></pre>
  
  <p>...would be sufficient?
  Because the Type is bool, is it safe? if so, when does it become not safe?
  byte? int? DateTime?</p>
  
  <p><em>edit</em><br>
  My basic architecture is to have this class store state. Maybe have one service in charge of doing the writes to this class. All the other classes can read and perform their logic based on this state data. I will do my best to make sure all data is consistent, but as stated below, my main concern was the atomicity and splinching of data.</p>
  
  <p><strong>Conclusion</strong><br>
  Thanks everyone for their response, all were valuable. My main concern was of atomicity of the writes/reads (i.e. worried about splinching). For the .NET platform, if the variable in question is a built-in value type that is less than 4 bytes, then the read and write is atomic (ex. short and int are fine, long and double are not).</p>