Critical section with two different "rights of way" [closed]

Question

In C#, how do I handle critical section with two different "rights of way"?

Theoretical use case: imagine a swimming pool (the resource). Many individual swimmers (worker threads A, B, C, and D) can swim into the pool as they feel like to, and its totally OK for multiple swimmers to be in the pool concurrently. However, from time to time there is a private swimming class (another worker thread, E), and the class has rights above all other swimmers. When a class starts, all other swimmers are asked to complete their task (and exit the pool ASAP).

Swimmers who were asked to leave the pool have already taken their shower and left the premise, as technically, they had already completed their task. Any individual swimmer who arrived after the class started must sit on the bench and wait until the class is over before they can swim.

--

Dealing with concurrency I am used to the lock statement but in this case this would result in only one swimmer (thread) at any time, which is not acceptable.

Answer 1

You're looking for a shared-read/exclusive-write type lock. C# provides that with the ReaderWriterLockSlim Class. The individual swimmers correspond to threads that have read access, while the swimming class would request exclusive write access.

Note that this kind of lock is available in many libraries and languages, so this is not specifically a C# answer, although the referenced class belongs to C# or more precisely the .NET framework.

Answer 2

So you can use SemaphoreSlim to make a lock with an arbitrary number of concurrent threads.

https://docs.microsoft.com/en-us/dotnet/api/system.threading.semaphoreslim?view=net-5.0

But your swimming class logic is going to need some custom code. I would add a second SwimClass Semaphore with just a single thread, a flag isSwimClassInProgress which is set when a swim class comes along.

Swim(swimmer s)
{

    if(IsSwimClassInProgress)
    {
        await SwimClass.Wait(); //wait for class to end
    }
    await SwimLane.Wait() //wait for free lane and then take it (up to X allowed)
    if(s.IsSwimClass)
    {
        await SwimClass.Wait();
        IsSwimClassInProgress = true; //new swimmers will wait for end of swim class
    }
    //spin up a swimmer thread to do stuff
    if(s.IsSwimClass)
    {
        await SwimClass.Release(); //allow swimmers back in the pool
        IsSwimClassInProgress = false; //needs to be made thread safe
    }
    SwimLane.Release(); //release your lane
}

Not perfect but demonstrates the idea

Answer 3

I did not formulate the question correctly.

For instance, It turns out I did not need to lock a "resource" (the pool, or a swimming lane), but rather needed to prevent swimmers to collide by essentially swimming at the same spot, at the same time. For my particular need, it is OK to deny a second swimmer's access, if I know another swimmer is already doing the work I expect it to do.

I found the best way to do this is to register a queue of tasks, as hinted by @user253751:

private Dictionary<Guid, Task> _ordersTasks;

Adding a task is the responsibility of a front-desk. Tasks will not be added to the queue if there is already a duplicate. A task is considered duplicate if the key (Guid) of the registered task is already in the dictionary.

public void AddTaskToQueueIfNotExists(Guid uuid, Task task)
{
    Task existingTask;

    var taskAlreadyExists = _ordersTasks.TryGetValue(uuid, out existingTask);

    if (taskAlreadyExists)
    {
        // Must allow task to rerun if a previous task was not completed successfully.
        if (existingTask.IsCompletedSuccessfully)
        {
            // Do not add the task.
            return;
        }
        else
        {
            // Previous task failed. Remove old task and replace it to rerun
            _ordersTasks.Remove(uuid);
        }
    }

    _ordersTasks.Add(uuid, task);
}

In this basic implementation, the tasks get started as soon as they are added to the queue using _ordersTasks.Add(uuid, task);. But, it would be totally possible to add more control, eg. delaying execution of a task, or allocating tasks to a number of threads (the "swimming lanes") etc.