Check whether the MVar
is empty.
Check whether the MVar
is empty.
Notice that the boolean value returned is just a snapshot of the state of
the MVar
. By the time you get to react on its result, the MVar
may have
been filled (or emptied) - so be extremely careful when using this
operation. Use tryTake
instead if possible.
A slight variation on update
that allows a value to be returned (b
) in
addition to the modified value of the MVar
.
Put a value into an MVar
.
Put a value into an MVar
. If the MVar
is currently full, put
will
wait until it becomes empty.
Atomically read the contents of an MVar
.
Atomically read the contents of an MVar
. If the MVar
is currently
empty, read
will wait until it is full. read
is guaranteed to receive
the next put
.
Take a value from an MVar
, put a new value into the MVar
and return the
value taken.
Return the contents of the MVar
.
Return the contents of the MVar
. If the MVar
is currently empty, take
will wait until it is full. After a take
, the MVar
is left empty.
A non-blocking version of put
.
A non-blocking version of put
. The tryPut
function attempts to put the
value x
into the MVar
, returning true
if it was successful, or
false
otherwise.
A non-blocking version of read
.
A non-blocking version of read
. The tryRead
function returns
immediately, with None
if the MVar
was empty, or Some(x)
if the
MVar
was full with contents x
.
A non-blocking version of take
.
A non-blocking version of take
. The tryTake
action returns immediately,
with None
if the MVar
was empty, or Some(x)
if the MVar
was full
with contents x
. After tryTake
, the MVar
is left empty.
Replaces the contents of an MVar
with the result of f(a)
.
An
MVar[A]
is a mutable location that is either empty or contains a value of typeA
. It has two fundamental operations:put
which fills anMVar
if it is empty and blocks otherwise, andtake
which empties anMVar
if it is full and blocks otherwise. They can be used in multiple different ways:take
andput
asreceive
andsend
, andMVar[Unit]
, withtake
andput
aswait
andsignal
.They were introduced in the paper "Concurrent Haskell" by Simon Peyton Jones, Andrew Gordon and Sigbjorn Finne.