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-phone...
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