Does this small C# template make (almost) any data thread safe?

Question

The use case is this:

• One thread writes data, using SetData()
• Multiple threads may read data, using GetData()
• I plan to only use basic data types or structs as T

With these rules in mind, is this thread safe?

    public struct ThreadSafeData<T>
    {
        private T[] dataArray;

        private int setterIndex;        
        private int lastSetIndex;

        public void Init()
        {
            dataArray = new T[2];
        }

        public void SetData(T data)
        {
            dataArray[setterIndex] = data;            
            lastSetIndex = setterIndex;

            // Convert 0 to 1, and 1 to 0
            setterIndex = lastSetIndex * - 1 + 1;
        }

        public T GetData()
        {            
            return dataArray[lastSetIndex];
        }
    }

UPDATE (requested in comments)

What I would like to achieve is the following; I want to avoid tearing and want the reader to always read the last value written by the writer. I tried doing that with a single T field, but then I encountered (what I think is) tearing. For example, in the tests (see below) I always write a Vector2Int with 0,0 or 1,1. But the reader would sometimes read 1,0 when using a single T field. This is why I added the Array (and added the "data integrity" check to my tests).

I am using X64 architecture. And this is the Vector2Int I use in my tests: https://docs.unity3d.com/ScriptReference/Vector2Int.html

Questions

1. How do I know if this is thread safe (if it is)? I have run tests for quite a while. But how do I know for sure?

2. Do you know a better solution for this use case? Please let me know!

Tests

I am making a game in Unity and have run tests where the "writing thread" runs at 30, 60 or 90fps, and doing up to 300 writes per frame. And a "reading thread" running from 30 to 300fps (doing 1 read per frame).

The test data (T) I used was a struct with a Vector2Int and a bool. To check the data integrity, the "reader" checked if the x and y of the Vector2Int are 1 when the bool is true and when false, x and y have to be 0 (it throws an error when this is wrong).

I ran these test for about an hour and never got any errors. But I am not sure if that means that this always works correct.

(ps. I don't really care if this template is a struct or class; I am not sure yet what will work best for me)

Answer 1

I managed to reproduce a torn value with your ThreadSafeData implementation, using as T the type ValueTuple<int, int, int, int, int, int, int, int, int>, and mutating it using the same Random.Next() value for all nine fields of the tuple. Demo. Hundreds of torn T values per second are observed. Like this value:

(373331022, 373331022, 373331022, 373331022, 373331022, 373331022, 373331022, 1480972221, 1480972221)

Here are some alternative implementations of the ThreadSafeData<T> struct, that are truly safe. Using the lock statement is definitely thread-safe, and also very simple:

public struct ThreadSafeData<T>
{
    private readonly object _locker = new();
    private T _data = default;
    public ThreadSafeData() { }
    public void SetData(T data) { lock (_locker) _data = data; }
    public T GetData() {  lock (_locker) return _data; }
}

The cost of an uncontended lock is in the magnitude of ~20 nanoseconds, so it's quite cheap, but if your readers are calling the GetData very frequently then you might want a faster solution. This solution is not the ReaderWriterLockSlim though:

public struct ThreadSafeData<T>
{
    private readonly ReaderWriterLockSlim _lock = new();
    private T _data = default;
    public ThreadSafeData() { }
    public void SetData(T data)
    {
        _lock.EnterWriteLock();
        try { _data = data; }
        finally { _lock.ExitWriteLock(); }
    }
    public T GetData()
    {
        _lock.EnterReadLock();
        try { return _data; }
        finally { _lock.ExitReadLock(); }
    }
}

This is actually a little slower than the lock, because the work that is performed by the writer is too lightweight. The ReaderWriterLockSlim is advantageous when the writer does chunky work.

A better alternative regarding performance, but worse regarding memory allocations, is to store the T value in a volatile object field:

public struct ThreadSafeData<T>
{
    private volatile object _data = default(T);
    public ThreadSafeData() { }
    public void SetData(T data) => _data = data;
    public T GetData() => (T)_data;
}

This will cause boxing in case the T is a value type, and a new box will be allocated on each SetData operation. According to my experiments the size of the box is 16 bytes + the size of the T. The performance boost compared to the lock (in scenarios with high contention), is around x10.

---

Seqlock: Peter Cordes mentioned in their answer the interesting idea of the Seqlock. Below is an implementation of this idea. My tests don't reveal any tearing. Most likely the implementation below is safe for a single writer - multiple readers scenario, but I wouldn't bet my life on it. The advantage of this approach over the above volatile object, is that it doesn't allocate memory.

public struct ThreadSafeData<T> // Safe with a single writer only
{
    private volatile int _seq;
    private T _data;

    public void SetData(T data)
    {
        _seq++;
        Interlocked.MemoryBarrier();
        _data = data;
        _seq++;
    }

    public T GetData()
    {
        SpinWait spinner = default;
        while (true)
        {
            int seq1 = _seq;
            if ((seq1 & 1) != 0) goto spin;
            T data = _data;
            Interlocked.MemoryBarrier();
            int seq2 = _seq;
            if (seq1 != seq2) goto spin;
            return data;
        spin:
            spinner.SpinOnce();
        }
    }
}

According to my experiments the performance of the GetData() is about half of the corresponding volatile object-based implementation, but still many times faster than the lock-based, under the condition that the SetData is called infrequently. Otherwise, if the writer calls the SetData in a tight loop, the readers will barely be able to read any value at all. Almost always the _seq will be different before and after reading the _data, resulting in endless spinning.

Answer 2

2 int elements is only 64 bits; mainstream x86 and ARM CPUs can do 64-bit atomic stores and load (even when running in 32-bit mode), so the optimal approach would be convincing your compiler to do that. (Like C++ std::atomic<my_struct> with memory_order_relaxed, or in C# perhaps just packing both members into a uint64_t, if you can get the necessary visibility guarantees for your code as well as atomicity.)

Remember that plain variables don't guarantee visibility across threads unless there's other synchronization: reading a variable in a loop can optimize to reading it into a register once, and using that value every time. Any time a load or store does happen, it's atomic, but without volatile or Volatile.Read / .Write, nothing guarantees that loads / stores happen in the asm as often as they do in the source.

---

In general, you might be looking for the SeqLock, where the reader retries until it gets a non-torn read of the payload + sequence number. See

• Implementing 64 bit atomic counter with 32 bit atomics (seqlock discussion with C++ example)
• A readers/writer lock... without having a lock for the readers? (SeqLock or RCU)
• Atomic and lock-free write of arbitrary sized data/vector/array (C++)
• How to get a stable version of mutiple values at a particular time without lock? (C# ConcurrentQueue which uses a strategy similar to a SeqLock of re-reading members until it gets a consistent read, which has some limitations. IDK if spin.SpinOnce(); has any compile-time-memory-barrier semantics, or if the members they're reading were declared volatile.)

If only one thread ever writes, you don't need any atomic RMWs, just atomic stores of the sequence number before/after plain stores of the payload. But you do need strict ordering of the stores in the writer and loads in the reader. And the first load of the sequence number does have to be an acquire load, like Volatile.Read.

I ran these test for about an hour and never got any errors.

If you tested on x86, LoadLoad and StoreStore reordering are impossible, so if your algorithm is equivalent enough to a SeqLock, then it will be safe on x86 if the compiler doesn't reorder operations at compile time. Having two separate "index" (sequence number?) variables would stop the compiler from doing dead-store elimination. Using just plain C# vars without anything equivalent to C++ std::atomic_thread_fence(acquire) / release will break on AArch64, though, were plain variables get weaker run-time ordering than on x86.

---

Your implementation isn't really like a SeqLock, it's like a 2-element queue depending on a memory_order_consume type of dependency-ordering which is a thing even on weakly-ordered ISAs like AArch64. But if another write happens while a reader is still reading, you'll spoil their data.

So it's like RCU (read copy update), with its advantage over a SeqLock that there's always a consistent state to read. But you reuse the old state on the very next write, so even if you write infrequently, a reader that gets descheduled by the OS could wake up and read inconsistent data if that happens at the same time the writer is writing the same slot it's reading.

RCU can work well in a garbage-collected language like C#, if you allocate a new object and update a reference on write. Garbage collection solves the deallocation problem, which is the hardest part of RCU (knowing when all other threads definitely aren't still reading an old copy of the payload).

You're replacing the whole payload, so not actually copying and modifying e.g. an array or binary tree, so that makes it even easier.

---

P.S. The only part of C# I know is some memory-model stuff and SIMD intrinsics, because that's where the tags I follow overlap with it. That's why my answer is basically citing C++ equivalents for what's possible. I never planned to write a real answer to this, but my comments kind of became almost an answer.

If someone else wants to write a C# SeqLock implementation or example, please post it as an answer here or on a related C# question.