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
swapMVar and mofifyMVar are guaranteed to be atomic iirc
Tom
El May 6, 2015, a las 15:19, Tom Ellis
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
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-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
I hope I'm not derailing, but unless you have a good reason not to do so, please use STM instead of MVars. Best regards, Marcin Mrotek
One of the good ways of thinking about MVars is to think about it
either like lock with value, or channel with one position.
And divide API into two parts.
In former case use operations: withMVar, modifyMVar, swapMVar,
readMVar (ghc>=7.8). This could be used for locking or keeping
mutable shared state.
In latter: takeMVar, putMVar, readMVar. This could be used for message
communication.
In any of this case you are safe from the situations mentioned above, however
if you use both, then you are in the grey area, and have to consider
all scenarios.
About your question: yes another process could put value inside MVar and
your process will be locked unless somebody will read a value.
--
Alexander
On 6 May 2015 at 22:19, Tom Ellis
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
-- Alexander
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
On 07-05-2015 09:53, Takenobu Tani wrote:
So here is few related illustration:) "MVar" section http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf
Great slides, thanks for sharing! :) -- Felipe.
Tom Ellis 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-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?
You are absolutely right. It's exactly the same as with the more traditional semaphores, i.e. locking happens if and only if all involved parties adhere to the protocol (take lock; do something; give lock). It is usually best to enforce adherence to the protocol on the module level by not exporting anything that exposes the MVar itself (and using bracket or, even better, withMVar or modifyMVar internally). Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams
participants (8)
-
Alexander V Vershilov -
amindfv＠gmail.com -
Ben Franksen -
Felipe Lessa -
Marcin Mrotek -
Ryan Yates -
Takenobu Tani -
Tom Ellis