Consider supporting in-memory locking above the distributed layer (composite locking)

Right now, if the same process tries to claim a lock, we push this out to the distributed locking layer (e. g. SQL).

We could reduce resource usage by first checking an internal lock (e. g. a SemaphoreSlim). We have to be very careful about how this interops with modes, though.

Current thinking on this: rather than build this into multi-plexing, we could offer a wrapper lock for any IDistributedLock that would add an in-process synchronization layer.

Some thoughts on composite locks:

1. This should be more complex than just take lock a, take lock b. For example, let’s say we have N local waiters for a the lock and then the first one of those acquires the distributed lock. We shouldn’t release that until all those N local waiters have gotten to hold the lock or given up (new local waiters that come in after we got the distributed lock shouldn’t get to join in; otherwise we might hog the distributed lock indefinitely). The benefit of this system is that it prevents a service using composite locking from always losing out to a service that doesn’t, and also decreases the number of distributed lock operations (more efficient). The downside is that it reduces fine-grained interleaving of lock requests between services. Note that for R/W locks where we have both Write and UpgradeableRead, we have to be careful that the underlying lock is the right type.

2. We need to be careful with R/W locks if they have writer-jumps-reader behavior. We wouldn’t want a scenario where writers are queued up behind a local read lock hold which is then queued up waiting for a distributed write lock hold to be released. We might want to only use the local lock for writes and upgradeable reads in order to prevent this.

3. We need to be careful with upgradeable reads. If we are holding an upgradeable read lock and try to upgrade, we might succeed locally but fail remotely, leaving ourselves with no way to back out of the local upgrade. To solve this, we can have the upgrade operation be remote-only.

[madelson]

@darkflame0 ok prerelease is out (https://www.nuget.org/packages/DistributedLock.ProcessScoped/1.0.0-alpha01). Let me know if you get a chance to give it a try. This doesn’t support composite locking yet, just the process-scoped named lock types you were asking about.

[darkflame0]

but wait handles is unavailable if on linux. I still think should have a InMemory Implementation. It is beneficial to both test and single application