`AsyncReaderWriterLock` Contention Strategy about protopromise HOT 5 CLOSED

That would be useful.

I have a use case where it is preferable when specific scopes can be prioritized.

So maybe something like ContentionStrategy.PrioritizeSelective could also be done.

I think of something like this:

private readonly AsyncReaderWriterLock _rwl = new AsyncReaderWriterLock();

public async Promise DoStuffAsync()
{
    using (await _rwl.UpgradeableReaderLockAsync(Priority.Low))
    {
        // Reader lock is shared, multiple readers can enter at the same time.
    }

    using (await _rwl.ReaderLockAsync(Priority.High))
    {
        // Prioritized Reader lock is shared, multiple readers can enter at the same time.
    }
    
    using (await _rwl.WriterLockAsync(Priority.Middle))
    {
        // Writer lock is mutually exclusive, only one writer can enter at a time, and no readers can enter while a writer is entered.
    }
}

Maybe ContentionStrategy.PrioritizeSelective could be a replacement for all other ContentionStrategies other then Balanced?

from protopromise.

@timonkrebs That's an interesting idea. I'm not sure how feasible or cheap that would be to implement. I have to consider the strategy both when locks are acquired as well as when they are released. If different locks of the same type can have different priorities dynamically, that's not just a simple field in the class.
And that sounds like you want a lock to "jump the line" if it's higher priority than a pending lock, correct?

from protopromise.

Yes I think of it something like "jump the line". I think it could be done with 9 queues.
For every case one queue. Like

• ReaderLockHigh
• ReaderLockMiddle
• ReaderLockLow
• UpgradeableReaderLockHigh
• UpgradeableReaderLockMiddle
• UpgradeableReaderLockLow
• WriterLockHigh
• WriterLockMiddle
• WriterLockLow

Not sure if it is worth the added complexity. I only mentioned it because I think it could be done without to much effort.

from protopromise.

My idea here was to simply pass the strategy into the constructor new AsyncReaderWriterLock(ContentionStrategy.PrioritizeReaders), with that I can store the strategy in a field and use it to adjust the behavior almost for free (not adding extra branches).

Adding 9 queues could probably work, but it would definitely make the implementation much more complex, and it'd make the memory footprint of the lock much bigger. I don't think it's worth it to add that to the lock as it would slow down other more common cases where dynamic prioritization is not needed. This seems like a case where you'd want a specialized lock for your special need.

from protopromise.

This seems like a case where you'd want a specialized lock for your special need.

That is probably true... Your initial solution is probably better for most cases. My needs are quite specialized. I wrote a new kind of lock that I call AsymmetricLock for my needs.

from protopromise.