CODEWITHSUNDEEP
c#multithreadinglocking
Randy Minder
Randy Minder

Reputation: 48392

Thread Synchronization in .NET

In my app I have a List of objects. I'm going to have a process (thread) running every few minutes that will update the values in this list. I'll have other processes (other threads) that will just read this data, and they may attempt to do so at the same time.

When the list is being updated, I don't want any other process to be able to read the data. However, I don't want the read-only processes to block each other when no updating is occurring. Finally, if a process is reading the data, the process that updates the data must wait until the process reading the data is finished.

What sort of locking should I implement to achieve this?

Upvotes: 2

Views: 754

Answers (3)

Brian Gideon
Brian Gideon

Reputation: 48949

You could use ReaderWriterLockSlim. It would satisfy your requirements precisely. However, it is likely to be slower than just using a plain old lock. The reason is because RWLS is ~2x slower than lock and accessing a List would be so fast that it would not be enough to overcome the additional overhead of the RWLS. Test both ways, but it is likely ReaderWriterLockSlim will be slower in your case. Reader writer locks do better in scenarios were the number readers significantly outnumbers the writers and when the guarded operations are long and drawn out.

However, let me present another options for you. One common pattern for dealing with this type of problem is to use two separate lists. One will serve as the official copy which can accept updates and the other will serve as the read-only copy. After you update the official copy you must clone it and swap out the reference for the read-only copy. This is elegant in that the readers require no blocking whatsoever. The reason why readers do not require any blocking type of synchronization is because we are treating the read-only copy as if it were immutable. Here is how it can be done.

public class Example
{
  private readonly List<object> m_Official;
  private volatile List<object> m_Readonly;

  public Example()
  {
    m_Official = new List<object>();
    m_Readonly = m_Official;
  }

  public void Update()
  {
    lock (m_Official)
    {
      // Modify the official copy here.
      m_Official.Add(...);
      m_Official.Remove(...);

      // Now clone the official copy.
      var clone = new List<object>(m_Official);

      // And finally swap out the read-only copy reference.
      m_Readonly = clone;
    }
  }

  public object Read(int index)
  {
    // It is safe to access the read-only copy here because it is immutable.
    // m_Readonly must be marked as volatile for this to work correctly.
    return m_Readonly[index];
  }
}

The code above would not satisfy your requirements precisely because readers never block...ever. Which means they will still be taking place while writers are updating the official list. But, in a lot of scenarios this winds up being acceptable.

Upvotes: 2

Bevan
Bevan

Reputation: 44307

You don't make it clear whether the updates to the list will involve modification of existing objects, or adding/removing new ones - the answers in each case are different.

To handling modification of existing items in the list, each object should handle it's own locking.

To allow modification of the list while others are iterating it, don't allow people direct access to the list - force them to work with a read/only copy of the list, like this:

public class Example()
{
    public IEnumerable<X> GetReadOnlySnapshot()
    {
        lock (padLock)
        {
            return new ReadOnlyCollection<X>( MasterList );
        }
    }

    private object padLock = new object();
}

Using a ReadOnlyCollection<X> to wrap the master list ensures that readers can iterate through a list of fixed content, without blocking modifications made by writers.

Upvotes: 2

Marcin Deptuła
Marcin Deptuła

Reputation: 11957

This is what you are looking for.

ReaderWriterLockSlim is a class that will handle scenario that you have asked for. You have 2 pair of functions at your disposal:

  • EnterWriteLock and ExitWriteLock
  • EnterReadLock and ExitReadLock

The first one will wait, till all other locks are off, both read and write, so it will give you access like lock() would do.

The second one is compatible with each other, you can have multiple read locks at any given time.

Because there's no syntactic sugar like with lock() statement, make sure you will never forget to Exit lock, because of Exception or anything else. So use it in form like this:

try
{
lock.EnterWriteLock(); //ReadLock

//Your code here, which can possibly throw an exception.

}
finally
{
lock.ExitWriteLock(); //ReadLock
}

Upvotes: 5

Related Questions