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 se

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

Answer 2

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.

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