An MVar t is mutable location that is either empty or contains a
value of type t. It has two fundamental operations: putMVar
which fills an MVar if it is empty and blocks otherwise, and
takeMVar which empties an MVar if it is full and blocks
otherwise. They can be used in multiple different ways:

As synchronized mutable variables,
2. As channels, with takeMVar and putMVar as receive and send, and
3. As a binary semaphore MVar (), with takeMVar and putMVar as
wait and signal.

They were introduced in the paper Concurrent Haskell by Simon
Peyton Jones, Andrew Gordon and Sigbjorn Finne, though some details
of their implementation have since then changed (in particular, a
put on a full MVar used to error, but now merely blocks.)

Applicability

MVars offer more flexibility than IORefs, but less flexibility
than STM. They are appropriate for building synchronization
primitives and performing simple interthread communication; however
they are very simple and susceptible to race conditions, deadlocks or
uncaught exceptions. Do not use them if you need perform larger
atomic operations such as reading from multiple variables: use STM
instead.

No thread can be blocked indefinitely on an MVar unless another
thread holds that MVar indefinitely. One usual implementation of
this fairness guarantee is that threads blocked on an MVar are
served in a first-in-first-out fashion, but this is not guaranteed
in the semantics.

Gotchas

Like many other Haskell data structures, MVars are lazy. This
means that if you place an expensive unevaluated thunk inside an
MVar, it will be evaluated by the thread that consumes it, not the
thread that produced it. Be sure to evaluate values to be placed
in an MVar to the appropriate normal form, or utilize a strict
MVar provided by the strict-concurrency package.

Ordering

MVar operations are always observed to take place in the order
they are written in the program, regardless of the memory model of
the underlying machine. This is in contrast to IORef operations
which may appear out-of-order to another thread in some cases.

Example

Consider the following concurrent data structure, a skip channel.
This is a channel for an intermittent source of high bandwidth
information (for example, mouse movement events.) Writing to the
channel never blocks, and reading from the channel only returns the
most recent value, or blocks if there are no new values. Multiple
readers are supported with a dupSkipChan operation.

A skip channel is a pair of MVars. The first MVar contains the
current value, and a list of semaphores that need to be notified
when it changes. The second MVar is a semaphore for this particular
reader: it is full if there is a value in the channel that this
reader has not read yet, and empty otherwise.

This example was adapted from the original Concurrent Haskell paper.
For more examples of MVars being used to build higher-level
synchronization primitives, see Control.Concurrent.Chan and
Control.Concurrent.QSem.

takeMVar is single-wakeup. That is, if there are multiple
threads blocked in takeMVar, and the MVar becomes full,
only one thread will be woken up. The runtime guarantees that
the woken thread completes its takeMVar operation.

When multiple threads are blocked on an MVar, they are
woken up in FIFO order. This is useful for providing
fairness properties of abstractions built using MVars.

putMVar is single-wakeup. That is, if there are multiple
threads blocked in putMVar, and the MVar becomes empty,
only one thread will be woken up. The runtime guarantees that
the woken thread completes its putMVar operation.

When multiple threads are blocked on an MVar, they are
woken up in FIFO order. This is useful for providing
fairness properties of abstractions built using MVars.

This is a combination of takeMVar and putMVar; ie. it takes the value
from the MVar, puts it back, and also returns it. This function
is atomic only if there are no other producers (i.e. threads calling
putMVar) for this MVar.

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 tryTakeMVar instead if possible.

withMVar is an exception-safe wrapper for operating on the contents
of an MVar. This operation is exception-safe: it will replace the
original contents of the MVar if an exception is raised (see
Control.Exception). However, it is only atomic if there are no
other producers for this MVar.

An exception-safe wrapper for modifying the contents of an MVar.
Like withMVar, modifyMVar will replace the original contents of
the MVar if an exception is raised during the operation. This
function is only atomic if there are no other producers for this
MVar.