Documentation

Strict MVar (modelled using a lazy TMVar under the hood)

The StrictMVar API is slightly stronger than the usual MVar one, as we offer a primitive to read the value of the MVar even if it is empty (in which case we will return the oldest known stale one). See readMVarSTM.

There is a weaker invariant for a StrictMVar than for a StrictTVar: although all functions that modify the StrictMVar check the invariant, we do not guarantee that the value inside the StrictMVar always satisfies the invariant. Instead, we do guarantee that if the StrictMVar is updated with a value that does not satisfy the invariant, an exception is thrown. The reason for this weaker guarantee is that leaving an MVar empty can lead to very hard to debug "blocked indefinitely" problems.

This is also the reason we do not offer support for an invariant in StrictTMVar: if we throw an exception from an STM transaction, the STM transaction is not executed, and so we would not even be able to provide the weaker guarantee that we provide for StrictMVar.

Create an initially empty StrictMVar

NOTE: Since readMVarSTM allows to read the StrictMVar even when it is empty, we need an initial value of a even though the StrictMVar starts out empty. However, we are NOT strict in this value, to allow it to be error.

Read the possibly-stale value of the MVar

Will return the current value of the MVar if it non-empty, or the last known value otherwise.

Swap value of a StrictMVar

NOTE: Since swapping the value can't leave the StrictMVar empty, we could check the invariant first and only then swap. We nonetheless swap first and check the invariant after to keep the semantics the same with putMVar, otherwise it will be difficult to understand when a StrictMVar is updated and when it is not.