dazinator
commented
4 years ago Seems sensible. To go one step further, before pushing to the distributed lock layer, it might also be valuable to add a SystemDistributedLock layer in front of that again - depending on circumstance.
Question: is it a desire of this package to provide any kind of common IDistributedLock abstraction that all concrete providers will implement at a minimum? Or will it just provide different concrete lock implementations with no common interface, and leave it for application developers to build there own common abstractions around them if needed? If it's the latter then I can quickly see myself wanting to create my own common IDistributedLock abstraction, and some form of CompositeDistributedLock that implements the same interface but can wrap an inner, ordered list of lock providers (in memory, system, sql etc) that it must Aquire() a lock from first, before proceeding to the next one in the list - ultimately either timing out waiting for a lock at each level, or returning a final CompositeDisposable which wraps each of the IDisposable locks obtained.
madelson
darkflame0
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:
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.
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.
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.