<div dir="ltr">When you are using an MVar as a lock, you will not want anyone to put something into the MVar without already being the *one* taking from the lock in the first place.  You can think of the value in the MVar as a token indicating that you are in the critical section that no other thread can be in unless they hold the token.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 3:19 PM, 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> wrote:<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>