Concurrency with reading but locking with mutating

问题

I'm looking for a solution that allows multiple threads to read the shared resource (concurrency permitted) but then locks these reading threads once a thread enters a mutating block, to achieve best of both world.

I've looked up this reference but it seems the solution is to lock both reading and writing threads.

class Foo {

    List<string> sharedResource;

    public void reading() // multiple reading threads allowed, concurrency ok, lock this only if a thread enters the mutating block below.
    {

    }

    public void mutating() // this should lock any threads entering this block as well as lock the reading threads above
    {
        lock(this)
        {
        }
    }
}

Is there such a solution in C#?

Edit

All threads entering in both GetMultiton and constructor should return the same instance. want them to be thread safe.

class Foo: IFoo {
    public static IFoo GetMultiton(string key, Func<IFoo> fooRef)
    {
        if (instances.TryGetValue(key, out IFoo obj))
        {
            return obj;
        }
        return fooRef();
    }

     public Foo(string key) {
          instances.Add(key, this);
     }
}

     protected static readonly IDictionary<string, IFoo> instances = new ConcurrentDictionary<string, IFoo>();

Use

  Foo.GetMultiton("key1", () => new Foo("key1"));

回答1:

There is a pre-built class for this behavior ReaderWriterLockSlim

class Foo {

    List<string> sharedResource;
    ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();

    public void reading() // multiple reading threads allowed, concurrency ok, lock this only if a thread enters the mutating block below.
    {
        _lock.EnterReadLock();
        try
        {
            //Do reading stuff here.
        }
        finally
        {
            _lock.ExitReadLock();
        }
    }

    public void mutating() // this should lock any threads entering this block as well as lock the reading threads above
    {
        _lock.EnterWriteLock();
        try
        {
            //Do writing stuff here.
        }
        finally
        {
            _lock.ExitWriteLock();
        }
    }
}

Multiple threads can enter the read lock at the same time but if a write lock tries to be taken it will block till all current readers finish then block all new writers and new readers till the write lock finishes.

With your update you don't need locks at all. Just use GetOrAdd from ConcurrentDictionary

class Foo: IFoo {
    public static IFoo GetMultiton(string key, Func<IFoo> fooRef)
    {
        return instances.GetOrAdd(key, k=> fooRef());
    }

     public Foo(string key) {
          instances.Add(key, this);
     }
}

Note that fooRef() may be called more than once, but only the first one to return will be used as the result for all the threads. If you want fooRef() to only be called once it will require slightly more complicated code.

class Foo: IFoo {
    public static IFoo GetMultiton(string key, Func<IFoo> fooRef)
    {
        return instances.GetOrAdd(key, k=> new Lazy<IFoo>(fooRef)).Value;
    }

     public Foo(string key) {
          instances.Add(key, new Lazy<IFoo>(()=>this);
     }
}

     protected static readonly IDictionary<string, Lazy<IFoo>> instances = new ConcurrentDictionary<string, Lazy<IFoo>>();

回答2:

The solution depends on your requirements. If performance of ReaderWriterLockSlim (note that it's approximately twice slower than regular lock in current .NET Framework, so maximum performance you can achieve if you modify rarely and reading is quite heavy operation, otherwise overhead will be more than profit), you can try to create copy of data, modify it and atomically swap reference with help of Interlocked class (if it's not a requirement to have the most recent data in each thread as soon as it was changed).

class Foo
{
    IReadOnlyList<string> sharedResource = new List<string>();

    public void reading()
    {
        // Here you can safely* read from sharedResource
    }

    public void mutating()
    {
        var copyOfData = new List<string>(sharedResource);

        // modify copyOfData here

        // Following line is correct only in case of single writer:    
        Interlocked.Exchange(ref sharedResource, copyOfData);
    }
}

Benefits of lock-free case:

We have no locks on read, so we get maximum performance.

Drawbacks:

We have to copy data => memory traffic (allocations, garbage collection)
Reader thread can observe not the most recent update (if it reads reference before it was updated)
If reader uses sharedResource reference multiple times, then we must copy this reference to local variable via Interlocked.Exchange (if this usages of reference assume that it's the same collection)
If sharedResource is a list of mutable objects, then we must be careful with updating this objects in mutating since reader might be using them at the same moment => in this case it's better to make copies of these objects as well
If there are several updater threads, then we must use Interlocked.CompareExchange instead of Interlocked.Exchange in mutating and a kind of a loop

So, if you want to go lock-free, then it's better to use immutable objects. And anyway you will pay with memory allocations/GC for the performance.
UPDATE
Here is version that allows multiple writers as well:

class Foo
{
    IReadOnlyList<string> sharedResource = new List<string>();

    public void reading()
    {
        // Here you can safely* read from sharedResource
    }

    public void mutating()
    {
        IReadOnlyList<string> referenceToCollectionForCopying;
        List<string> copyOfData;

        do
        {
            referenceToCollectionForCopying = Volatile.Read(ref sharedResource);
            copyOfData = new List<string>(referenceToCollectionForCopying);

            // modify copyOfData here
        } while (!ReferenceEquals(Interlocked.CompareExchange(ref sharedResource, copyOfData,
            referenceToCollectionForCopying), referenceToCollectionForCopying));
    }
}

来源：https://stackoverflow.com/questions/41865146/concurrency-with-reading-but-locking-with-mutating

标签

multithreading

concurrency

locking