ReaderWriterLockSlim EnterReadLock() over several methods, one running in a BackgroundWorker

Question

In my application I use a ReaderWriterLockSlim to synchronize reads and writes from/to a list<>.

In the following example reading the list is performed inside all 3 sub-methods, thus these 3 should be packed into a ReadLock. The problem is that SubMethod3 is called via a BackgroundWorker (as it contains lengthy calculations), so the ExitReadLock() in the finally block of MainMethod1 might be called before SubMethod3 has been finished by the BackgroundWorker (separate thread). Thereby the code in SubMethod3 is not really protected by the lock.

What I have considered is to use a lock in each sub-method, so Submethod3 would have its own lock, which would be released when the BackgroundWorker was done. The problem with this approach is that another thread could enter in between the calls of the sub-methods, as each of these would release the lock when done.

My question is: How can ReadLock be used to protect over more threads?

ReaderWriterLockSlim synchronizationLock = new ReaderWriterLockSlim();

public void MainMethod1()
    {
        synchronizationLock.EnterReadLock();
        try
        {
            SubMethod1(); //Run on UI thread
            SubMethod2(); //Run on UI thread
            myBackgroundWorker.RunWorkerAsync();  
        }
        finally
        {
            synchronizationLock.ExitReadLock();
        }
    }


private void myBackgroundWorker_DoWork(object sender, DoWorkEventArgs e)
        {
            SubMethod3(); //Run on separate thread
        }

Answer 1

In general you are out of luck. Due to thread affinity, you cannot release the lock from another thread. If you try to hold the reader lock (with the idea that this will allow the worker to acquire its own read lock), and wait the worker thread to start, acquire a reader lock and notify you, so you can release the read lock at that time, all you'll get would be a deadlock if there is a waiting writer thread due to reader/waiter fairness of the ReaderWriterLock(Slim) implementation.

I see the following options:

(A) Run the whole MainMethod1 on a separate thread.

(B) Write and use your own reader/writer lock implementation that supports such scenario.

(C) Get rid of BackgroundWorker and switch to async/await implementation using one of the AsyncReaderWriterLock implementations described here ReaderWriterLockSlim and async\await

(D) Since I've noticed the comment Run on UI thread, only and only if the method is used by a thread that supports marshalling calls from another thread (which is true for WF and WPF UI threads), you can use the following technique:

public void MainMethod1()
{
    synchronizationLock.EnterReadLock();
    bool releaseLock = true;
    try
    {
        SubMethod1();
        SubMethod2();
        RunWorkerCompletedEventHandler onRunWorkerCompleted = null;
        onRunWorkerCompleted = (sender, e) =>
        {
            ((BackgroundWorker)sender).RunWorkerCompleted -= onRunWorkerCompleted;
            synchronizationLock.ExitReadLock();
        };
        myBackgroundWorker.RunWorkerCompleted += onRunWorkerCompleted;
        myBackgroundWorker.RunWorkerAsync();
        releaseLock = false;
    }
    finally
    {
        if (releaseLock)
            synchronizationLock.ExitReadLock();
    }
}

Please note than while option (D) seems to solve the issue in the context of MainMethod1, it can easily lead to a deadlock if the UI thread tries to acquire read lock from another place and there is a pending writer waiting.

In general working with long time hold locks from the UI thread is a bad idea that is causing more problems rather than solving something. IMO the best are the options (A) and (C), and so far (A) is the simplest if you can afford it (if SubMethod1 and SubMethod2 do not need to be run on the UI thread or can marshall the necessary calls to it).