Function reord::maybe_lock
source · pub async fn maybe_lock()
Expand description
Potential lock-taking activity happening, that is impossible to encode with Lock
This should not be used if you can exactly define the locking behavior with Lock
, as it incurs
a heavy performance penalty: each time reord
will hit this point, it will continue assuming there
is no lock, and then if nothing happens during the time configured in Config
, it will assume
that a lock was actually taken and start running another task.
For these reasons, if using this, you should:
- Make sure this is just before the potentially-lock-taking operation
- Make sure you have a
point()
call just after the potentially-lock-taking operation - Make sure the lock-taking operation itself cannot be a source of non-determinism, as
reord
will run multiple of them in parallel when the lock is released, until they reach the nextpoint
- Make sure you do not have a panic or error that’d make code escape between the
maybe_lock
and its associatedpoint
, to stay reproducible - Use this as sparsely as possible
Unfortunately, there are circumstances that force the use of maybe_lock
. For example, postgresql
database access take locks that live for the lifetime of the transaction, that are basically impossible
to guess or otherwise encode in a clean locking format.