pub struct Transaction { /* private fields */ }
Expand description
Transaction tracks all the read and written variables.
It is used for checking vars, to ensure atomicity.
Implementations§
Source§impl Transaction
impl Transaction
Sourcepub fn with<T, F>(f: F) -> T
pub fn with<T, F>(f: F) -> T
Run a function with a transaction.
It is equivalent to atomically
.
Sourcepub fn with_control<T, F, C>(control: C, f: F) -> Option<T>
pub fn with_control<T, F, C>(control: C, f: F) -> Option<T>
Run a function with a transaction.
with_control
takes another control function, that
can steer the control flow and possible terminate early.
control
can react to counters, timeouts or external inputs.
It allows the user to fall back to another strategy, like a global lock in the case of too much contention.
Please not, that the transaction may still infinitely wait for changes when retry
is
called and control
does not abort.
If you need a timeout, another thread should signal this through a TVar
.
Sourcepub fn read<T: Send + Sync + Any + Clone>(
&mut self,
var: &TVar<T>,
) -> StmResult<T>
pub fn read<T: Send + Sync + Any + Clone>( &mut self, var: &TVar<T>, ) -> StmResult<T>
Read a variable and return the value.
The returned value is not always consistent with the current value of the var, but may be an outdated or or not yet commited value.
The used code should be capable of handling inconsistent states without running into infinite loops. Just the commit of wrong values is prevented by STM.
Sourcepub fn write<T: Any + Send + Sync + Clone>(
&mut self,
var: &TVar<T>,
value: T,
) -> StmResult<()>
pub fn write<T: Any + Send + Sync + Clone>( &mut self, var: &TVar<T>, value: T, ) -> StmResult<()>
Write a variable.
The write is not immediately visible to other threads, but atomically commited at the end of the computation.
Sourcepub fn or<T, F1, F2>(&mut self, first: F1, second: F2) -> StmResult<T>
pub fn or<T, F1, F2>(&mut self, first: F1, second: F2) -> StmResult<T>
Combine two calculations. When one blocks with retry
,
run the other, but don’t commit the changes in the first.
If both block, Transaction::or
still waits for TVar
s in both functions.
Use Transaction::or
instead of handling errors directly with the Result::or
.
The later does not handle all the blocking correctly.