[Haskell-cafe] MVars and locks

[Takenobu Tani]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150507/2f6c29dc/attachment.html>