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.

On Wed, May 6, 2015 at 3:19 PM, Tom Ellis <tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

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