Hi Tom,

Additional information.

MVar is low cost, fast and fairness operation. It's fantastic!
Although MVar is delicate about "order" including sync and async exceptions.

"order" means two levels.

 One is single MVar's order (putMVar, takeMVar).
 The other is inter-MVars order, such as the dining philosophers problem.


If you need robust systems more than performance critical systems.
It's better to use STM(TVar).
TVar is almost order free. It's amazing:-)


So here is few related illustration:)
  "MVar" section
  http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf

Enjoy,
Takenobu


2015-05-07 4:19 GMT+09:00 Tom Ellis <tom-lists-haskell-cafe-2013@jaguarpaw.co.uk>:
In the following section of the book "Parallel and Concurrent Programming in
Haskell"

    http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook

Simon Marlow explains that MVars can be used to implement something like
locks on shared functional state: "To acquire the lock, we take the MVar,
whereas, to update the variable and release the lock, we put the MVar."

Am I right in thinking this only holds if we are careful to ensure both
those operations happen in the given order?

For example, if I take the MVar (lock) and I am about to put something back
in (unlock) but someone else puts something in before I do, then the lock
system becomes broken, doesn't it?  So if we want to be sure we have a
robust lock system we have to wrap up MVars in another abstraction?

Tom

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe