Generic thread-safe data structure

Question

I wrote the following class so that a single object can be shared across many threads. Is using the ReaderWriterLockSlim redundant in this case and only Interlocked.Funcs() can do the job and ensure thread safety?

using System.Threading;


public class SharedData<T> where T:class
{
T _data;
ReaderWriterLockSlim _lock;

public SharedData(T arg)
{
    Interlocked.Exchange<T>(ref _data, arg);
    _lock = new ReaderWriterLockSlim();
}

public T Value
{
    get
    {
        _lock.EnterReadLock();
        var ret = Interlocked.CompareExchange<T>(ref _data, default(T), default(T));
        _lock.ExitReadLock();

        return ret;
    }
    set
    {
        _lock.EnterWriteLock();
        Interlocked.Exchange<T>(ref _data, value);
        _lock.ExitWriteLock();
    }
}
}

Answer 1

Using Interlocked on a class reference grants atomic transaction when you exchange an object for another;

For example, using

Interlocked.Exchange<T>(ref _data, value);

will exchange an object for an other, returning the previous object.

ReaderWriterLockSlim will protect some parts of your code, and you could also protect the object get/set with it.

Use only one of the lock, not both !

Also, you don't need usually to protect the initial set statement in your Ctor. Basically, you can only create a new object once in only one thread, before sharing anything related to this object.

One last point, with this code you are protecting the object reference, not the object itself. See below ...

class MyString {
    public string Data {get; set;}
}
...
var myString = new MyString() ;
var mySharedString = new SharedData<MyString>(myString) ;
...    
... thread 1
... mySharedString.Value.Data = "Hello" ;
...
... thread 2
... mySharedString.Value.Data = "BAD" ;

If the shared object is ReadOnly, it works, if the object is mutable, it will fail badly.

Answer 2

Try this out- it is thread safe and asynchronous.
This specific flavor does not enforce initialization, which is sometimes desirable is asynchronous scenarios.

There is a lot less overhead incurred when using this approach
As opposed to various synchronization primitives which revolve around blocking.

Consuming an asynchronous API enables your application to reuse the context, instead of wasting it by blocking. be it a UI context or a TPL Worker thread- they probably have better things to do than block.

Also note the use of the Interlocked API - it is an abstraction over a Hardware backed atomic operation which is orders of magnitude faster than locking.

public sealed class AsyncReference<T>
{

private TaskCompletionSource<T> _tcs;

public T Value
{
    set
    {
        var tcs = new TaskCompletionSource<T>();
        tcs.SetResult(value);

        TaskCompletionSource<T> previous = Interlocked.Exchange(ref _tcs, tcs);
        previous.TrySetResult(value);
    }
}

public Task<T> ValueAsync => _tcs.Task;

public AsyncReference()
{
    _tcs = new TaskCompletionSource<T>();
}

public AsyncReference(T value):this()
{
    _tcs.SetResult(value);
}

public static implicit operator Task<T>(AsyncReference<T> reference)
{
    if(reference==null)
        throw new InvalidOperationException($"null {typeof(AsyncReference<T>)} reference conversion is not supported");

    return reference._tcs.Task;
}

public static implicit operator AsyncReference<T>(T value)
{
    return new AsyncReference<T>(value);
}
}