Abstract Protected constructorUsed for creating read and write locks.
Used for creating locks when updating the counter.
Protected Readonly countProtected Readonly lockerPrivate acquireSafely updates the count before starting a read operation.
Protected Abstract getGenerate the identifier that will be used to acquire the count lock for the given identifier.
There will be cases where this lock needs to be acquired
while an active lock on the main resource is still being maintained.
This means that if the input resourceLocker and countLocker use the same locking system
this generated identifier needs to be different.
Protected Abstract modifyUpdate the counter that keeps track of having open read locks there currently are.
Identifier on which to update the number of read locks.
+1 or -1.
Private releaseSafely decreases the count after the read operation is finished.
Private withSafely runs an action on the count.
Protected withAcquires a new lock for the requested identifier. Will resolve when the input function resolves.
Identifier of resource that needs to be locked.
Function to resolve while the resource is locked.
Run the given function while the resource is locked. The lock will be released when the (async) input function resolves. This function should be used for operations that only require reading the resource.
Identifier of the resource that needs to be locked.
A function to execute while the resource is locked.
A promise resolving when the lock is released.
Run the given function while the resource is locked. The lock will be released when the (async) input function resolves. This function should be used for operations that could modify the resource.
Identifier of the resource that needs to be locked.
A function to execute while the resource is locked.
A promise resolving when the lock is released.
A ReadWriteLocker that allows for multiple simultaneous read operations. Write operations will be blocked as long as read operations are not finished. New read operations are allowed while this is going on, which will cause write operations to wait longer.
Based on https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Using_two_mutexes . As soon as 1 read lock request is made, the main lock is locked. Internally a counter keeps track of the amount of active read locks. Only when this number reaches 0 will the main lock be released again. The internal count lock is only locked to increase/decrease this counter and is released afterwards. This allows for multiple read operations, although only 1 at the time can update the counter, which means there can still be a small waiting period if there are multiple simultaneous read operations.
Classes extending this need to implement
getCountLockIdentifierandmodifyCount.