CODEWITHSUNDEEP
c#multithreadingthread-safety
ebvtrnog
ebvtrnog

Reputation: 4377

C# and thread-safety of a bool

I am very confused about this subject - whether reading/toggling a bool value is thread-safe.

    // case one, nothing
    private bool v1;
    public bool V1 { get { return v1; } set { v1 = value; } }

    // case two, with Interlocked on set
    private int v2;
    public int V2 { get { return v2; } set { Interlocked.Exchange(ref v2, value); } }

    // case three, with lock on set
    private object fieldLock = new object();
    private bool v3;
    public bool V3 { get { return v3; } set { lock (fieldLock) v3 = value; } }

Are all of them thread-safe?

EDIT

From what I have read (click) atomicity of bool does not guarantee it will be thread safe. Will then volatile type help?

Upvotes: 40

Views: 51592

Answers (3)

Roni Tovi
Roni Tovi

Reputation: 886

Nope, it isn't. But the solution is quite easy. To make a bool (or anything, actually) thread safe, it's easy to use lock statement like this:

object locker = new object();
protected bool _somebool;
public bool Somebool
{
    get
    {
        lock (locker)
            return _somebool;
    }
    set
    {
        lock (locker)
            _somebool = value;
    }
}

Now you may enjoy your thread safe of <T>.

Upvotes: 10

lilo0
lilo0

Reputation: 1035

A little bit late but should be useful to the others.

You can implement your own thread safe boolean in the following way:

// default is false, set 1 for true.
private int _threadSafeBoolBackValue = 0;

public bool ThreadSafeBool
{
    get { return (Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 1, 1) == 1); }
    set
    {
        if (value) Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 1, 0);
        else Interlocked.CompareExchange(ref _threadSafeBoolBackValue, 0, 1);
    }
}

Be sure to use Property everywhere, never access int variable directly.

Upvotes: 44

Yura
Yura

Reputation: 2421

No, not all of them are thread safe.

Case one isn't actually completely thread safe, or better saying - it isn't thread safe at all. Even if operations with boolean are atomic, variable value can be stored in a cache, and so, as in multicore CPU each core has it's own cache, value can be potentially corrupted.

Going even further, compiler and CPU can perform some internal optimizations, including instruction reordering, which can harmfully affect your program's logic.

You can add the volatile keyword, to notify the compiler that this field is used in a multi-threaded context. It will fix problems with cache and instruction reordering, but doesn't give you truly "thread safe" code (as write operations still will be not synchronized). Also volatile cannot be applied to local variable.

So when dealing with multi-threading you always have to use some technique of thread synchronization on valuable resources.

For more information - read this answer, which has some deeper explanation of different techniques. (example there is about int, but is doesn't really matter, it describes general approach.)

Upvotes: 38

Related Questions