C# and thread-safety of a bool

Question

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?

None of these are thread-safe. The thread that calls the getter will always read a stale value. How stale it is depends on the processor and the optimizer. Ranges from a handful of nanoseconds to infinity. The getter needs to synchronize as well. Or you'd use ManualResetEvent/Slim. — Hans Passant, Apr 02 '15 at 12:26
@Ksv3n *Assignement is always an atomic operation* False, `long` (64 bit) assignment by a 32 bit program isn't atomic. — xanatos, Apr 02 '15 at 13:00
@HansPassant A getter can read an old value, this is understandable. However, how could it last to infinity? Using a lock will make it read the *correct* value - reread it as if it was volatile? I don't think it works that way, I am confused about what you're saying. I thought that once nobody is writing anymore, the getter will work correctly. — ebvtrnog, Apr 02 '15 at 13:40
It will be infinity when the optimizer stores the backing variable in a processor register and doesn't reload it from memory. Because it doesn't know that another thread can update it. The x86 jitter does that if the bool isn't declared volatile. Example [is here](http://stackoverflow.com/a/458193/17034). — Hans Passant, Apr 02 '15 at 13:48

score 40 · Answer 1 · answered Mar 12 '18 at 11:04

40

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.

answered Mar 12 '18 at 11:04

lilo0

895
9
12

2

In the `get` why not use [`Interlocked.Read(ref _threadSafeBoolBackValue) == 1`](https://learn.microsoft.com/en-us/dotnet/api/system.threading.interlocked.read?view=netframework-4.8#remarks) instead of `Interlocked.CompareExchange`? – stomy Jul 04 '19 at 01:38
2

Simple, because where is no Interlocked.Read for `int` parameter. If you really want to use `Interlocked.Read` method, you may change back value type to `long`. – lilo0 Jul 04 '19 at 05:07
1

If I were to make `_threadSafeBoolBackValue` and `ThreadSafeBool` static for a class that is static, would thread safety will still valid? – Justin Mar 03 '21 at 20:14
1

@Justin Yes, it will. `Interlocked` methods didn't distinguish static and instance variables, and static initialization is thread safe. So, I see no problems in this case. – lilo0 Mar 04 '21 at 04:55
1

I just started using .Add(ref _threadSafeBoolBackValue, 0) == 1 – user1664043 May 17 '21 at 16:43
1

@user1664043 seems valid as well, good catch. Btw, the `set` method could also be simplified as `Interlocked.Exchange(ref _threadSafeBoolBackValue, value ? 1 : 0);` – lilo0 May 18 '21 at 12:50

score 38 · Accepted Answer · edited Nov 30 '17 at 17:43

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

*value can be potentially corrupted* No, value can't be corrupted (as in "transform in illegal/undefined value"). You could get stale ("old") values. — xanatos, Apr 02 '15 at 12:58
I mean "corrupted" in a way "not one, that it should be or you expect it to be". Definitely not a corrupted in a sense of memory corruption:) — Yura, Apr 02 '15 at 15:26

score 8 · Answer 3 · edited May 08 '22 at 20:51

8

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

edited May 08 '22 at 20:51

Theodor Zoulias

34,835
7
69
104

answered May 08 '22 at 20:10

Roni Tovi

828
10
21

this is thread safe but the order of execution is not guaranteed. Assume multiple threads want to write, the order of acquiring the lock may be different than the order of actually getting the lock. So you set true, false, true with three threads and the outcome may be true, true, false with a final value of false. – user2290269 Jun 06 '23 at 06:27

C# and thread-safety of a bool

3 Answers3

Linked

Related