<div dir="ltr"><div>Hi Tom,</div><div><br></div><div>Additional information.</div><div><br></div><div>MVar is low cost, fast and fairness operation. It's fantastic!</div><div>Although MVar is delicate about "order" including sync and async exceptions.</div><div><br></div><div>"order" means two levels.</div><div><br></div><div> One is single MVar's order (putMVar, takeMVar).</div><div> The other is inter-MVars order, such as the dining philosophers problem.</div><div><br></div><div><br></div><div>If you need robust systems more than performance critical systems.</div><div>It's better to use STM(TVar).</div><div>TVar is almost order free. It's amazing:-)</div><div><br></div><div><br></div><div>So here is few related illustration:)</div><div>  "MVar" section</div><div>  <a href="http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf">http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf</a></div><div><br></div><div>Enjoy,</div><div>Takenobu</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-07 4:19 GMT+09:00 Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the following section of the book "Parallel and Concurrent Programming in<br>
Haskell"<br>
<br>
    <a href="http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook" target="_blank">http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook</a><br>
<br>
Simon Marlow explains that MVars can be used to implement something like<br>
locks on shared functional state: "To acquire the lock, we take the MVar,<br>
whereas, to update the variable and release the lock, we put the MVar."<br>
<br>
Am I right in thinking this only holds if we are careful to ensure both<br>
those operations happen in the given order?<br>
<br>
For example, if I take the MVar (lock) and I am about to put something back<br>
in (unlock) but someone else puts something in before I do, then the lock<br>
system becomes broken, doesn't it?  So if we want to be sure we have a<br>
robust lock system we have to wrap up MVars in another abstraction?<br>
<br>
Tom<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div></div>