Function reord::maybe_lock

pub async fn maybe_lock()

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 next point
• Make sure you do not have a panic or error that’d make code escape between the maybe_lock and its associated point, 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.