Is locking access to a bool required or is it Overkill

Question

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.

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?

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

Is all this code overkill, and a simple...

public bool TheValue { get; set; }

...would be sufficient? Because the Type is bool, is it safe? if so, when does it become not safe? byte? int? DateTime?

edit
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.

Conclusion
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).

Answer 1

Depending on how this is being used, you may need to mark the boolean volatile. This will require a backing field to your property.

You should not need to handle this with the ReaderWriterLockSlim as you're doing now, since it's less than 32bits (assuming you're using AutoLayout, for details, see this post or, for the most detail, the section titled The Atomicity of Memory Accesses in the ECMA 335 spec). If you're using a type larger than this, then some form of synchronization will be required.

I would recommend:

public class MyClass
{
    private volatile bool _theValue = false;
    public bool TheValue 
    {
        get { return _theValue; } 
        set { _theValue = value; } 
    }
 }