Is locking access to a bool required or is it Overkill

问题

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

回答1:

You have a few options.

Do nothing.
Make the class immutable.
Use a plain old lock.
Mark the fields as volatile.
Use the Interlocked set of methods.

Since reads and writes to a bool are guaranteed to be atomic then you may not need to do anything. This will very much depend on the nature of the way your class is going to be used. Atomicity does not equal thread-safety. It is only one aspect of it.

The ideal solution is to make your class immutable. Immutable classes are generally thread-safe because they cannot be modified by other threads (or at all for that matter). Sometimes this just is not feasible though.

My next preference on the list is a plain old lock. The overhead of acquiring and releasing is very minimal. In fact, I think you will find that a lock will beat out a ReaderWriterLockSlim in most situations especially if all you are doing is reading/writing a variable. My own personal tests indicate that the overhead of RWLS is about 5x slower than a lock. So unless the read operations are unusually long and that they significantly outnumber write operations then RWLS will not help.

If you are concerned about lock overhead then by all means mark the fields as volatile. Just remember that volatile is not a magic bullet that solves all concurrency issues. It is not intended as a replacement for lock.

回答2:

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

回答3:

No type is truly safe! More precisely, the C# specifications assure you that reading or assignation of structure types less than 4 bytes or references are atomic. if your operating system is 64 bits, the CLR does a little better by assuring the same thing for structures less than 8 bytes.

But anything more complicated than an assignation or a read of a value can potentially be interrupted by another competing thread if you are not careful.

Even something as simple as this:

myBool = !myBool

can get an unexpected result if a competing thread modify the value of myBool.

Use of locks is advised if you want to be sure something like that does not happen. Use of the volatile keyword is strongly discouraged unless you know exactly what your doing. Check these blog posts for additionnal information.

However in your example where the property does not do anything else than a single write or a single read, locking is useless. But it would not be if there was any additionnal treatment.

来源：https://stackoverflow.com/questions/6433374/is-locking-access-to-a-bool-required-or-is-it-overkill

标签

multithreading

locking

readerwriterlockslim