Acquires a read lock.
Acquires a read lock. The transaction will suspend until no other fiber is holding a write lock. Succeeds with the number of read locks held by this fiber.
Acquires a write lock.
Acquires a write lock. The transaction will suspend until no other fibers are holding read or write locks. Succeeds with the number of write locks held by this fiber.
Retrieves the number of acquired read locks for this fiber.
Retrieves the number of acquired write locks for this fiber.
Just a convenience method for applications that only need reentrant locks, without needing a distinction between readers / writers.
Just a convenience method for applications that only need reentrant locks, without needing a distinction between readers / writers.
See writeLock.
Determines if any fiber has a read or write lock.
Obtains a read lock in a scoped context.
Determines if any fiber has a read lock.
Retrieves the total number of acquired read locks.
Releases a read lock held by this fiber.
Releases a read lock held by this fiber. Succeeds with the outstanding number of read locks held by this fiber.
Releases a write lock held by this fiber.
Releases a write lock held by this fiber. Succeeds with the outstanding number of write locks held by this fiber.
Runs the specified workflow with a lock.
Runs the specified workflow with a read lock.
Runs the specified workflow with a write lock.
Obtains a write lock in a scoped context.
Determines if a write lock is held by some fiber.
Computes the number of write locks held by fibers.
A
TReentrantLock
is a reentrant read/write lock. Multiple readers may all concurrently acquire read locks. Only one writer is allowed to acquire a write lock at any given time. Read locks may be upgraded into write locks. A fiber that has a write lock may acquire other write locks or read locks.The two primary methods of this structure are
readLock
, which acquires a read lock in a scoped context, andwriteLock
, which acquires a write lock in a scoped context.Although located in the STM package, there is no need for locks within STM transactions. However, this lock can be quite useful in effectful code, to provide consistent read/write access to mutable state; and being in STM allows this structure to be composed into more complicated concurrent structures that are consumed from effectful code.