Conditional thread lock in c#

Question

Is it possible to have a conditional thread lock when the underlying condition is not constant?

I have two functions A and B, and a condition to decide which function to execute. A is thread safe by itself, multiple calls to A can execute simultaneously, B is not, and is Synchronized. But during execution of B the condition can change (from false to true) and therefore all threads executing A at that time will throw errors.

if (condition)
{
    A();
}
else
{
    B();
}

A - thread safe
B - Synchronized using [MethodImpl(MethodImplOptions.Synchronized)]

Therefore, I am looking for a way to lock A but only when B is running. Please suggest a way to achieve this.

Some elaborations: I am creating a cache, and performance is very crucial, thus a blanket lock is not feasible.

Condition is whether or not the requested data is present in the cache.

A() = AddToUpdates() - Executed on a cache hit, just adds to the number of updates for a particular cache key, using a concurrent dictionary.

B() = ProccessUpdates() and EvictLeastPriorityEntry() - Executed on a cache miss, all previous updates will be processed and the underlying data structure storing the ordering of cache entries will be re-arranged.

And then the entry with least priority will be removed.

As mentioned in the accepted answer ReaderWriterLock seems to be the way to go.

Just one problem though, Let's say, thread1 starts execution and a cache hit occurs, (on the entry with the least priority) meaning the if condition is true and enters the if block. But before calling A(), control is switched to thread2.

thread2 - cache miss occurs, reordering and eviction (Entry which A() from thread1 needed access to) is performed.

Now when controlled is returned to thread1, error will occur.

This is the solution I feel should work:

_lock.EnterReadLock();
if (condition)
{
    A();
}
_lock.ExitReadLock();

if (!condition)
{
    B();
}

void A()
{
   // ....
}

void B()
{
    _lock.EnterWriteLock();
    // ...
    _lock.ExitWriteLock();
}

Will this work?

Thank you.

Answer 1

A possible solution to your problem might be the ReaderWriterLockSlim class. This is a synchronization primitive that allows multiple concurrent readers, or one exclusive writer, but not both of those at the same time.

Use ReaderWriterLockSlim to protect a resource that is read by multiple threads and written to by one thread at a time. ReaderWriterLockSlim allows multiple threads to be in read mode, allows one thread to be in write mode with exclusive ownership of the lock, and allows one thread that has read access to be in upgradeable read mode, from which the thread can upgrade to write mode without having to relinquish its read access to the resource.

Example:

private readonly ReaderWriterLockSlim _lock = new();

void A()
{
    _lock.EnterReadLock();
    try
    {
        //...
    }
    finally { _lock.ExitReadLock(); }
}

void B()
{
    _lock.EnterWriteLock();
    try
    {
        //...
    }
    finally { _lock.ExitWriteLock(); }
}

Answer 2

Your question looks a lot like this:

• A() is some read only method, so thread safe. Different execution of A in parallel is OK.

• B() is like writing/mutating things that A method uses. So A() becomes not thread safe if executed at same time.

For example B() could write in a List and A() executions read on this list. And you would get exception "InvalidOperationException: Collection Was Modified" thrown from A() .

I advise you to look for "producer/consumer problem" in google and look for the tons of example there are.

But in case you absolutely want to begins B execution while A execution(s) has/have not terminated, you can add checkpoint in A() using Monitor class, it is used to lock a resource and synchronize with other threads. It is more complex though and i would go first for producer/consumer pattern to see if it fill the needs

Some more things:

• I would check is the use of BlockingCollection<T> class that may fit your exact need too (and is easy to use)

• The use of MethodImplOptions.Synchronized is not recommended because it use public lock. We use usually use private lock (object readonly _lock = new object();) so no one except the maintainer of this object can lock on it, thus preventing dead lock (and preventing other people accusing your code of a bug because other people locked your instance of class without knowing you do the same internally)