
When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

Chad Scherrer wrote:
When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa?
No one is strictly better than the other. But there are practical implications of choosing between them. For instance, MVar (A,B) is less prone to deadlock issues than (MVar A, MVar B). Consider (a,b) :: (MVar A, MVar B) alice = do takeMVar a ; takeMVar b ; foo ; putMVar a x ; putMVar b y bob = do takeMVar b ; takeMVar a ; bar ; putMVar b w ; putMVar a z If alice and bob run concurrently, it might happen that alice takes a, bob takes b, and no one can proceed further. So, you must be very careful about the ordering of the takeMVar's (e.g. if you need both, always take a before taking b). There is no such issue using MVar (A,B), since only a single takeMVar is needed. On the other hand using MVar (A,B) may reduce concurrency, imposing unnecessary locks. If alice2 only needs a, why should she be blocked from bob2 using only b? This issue gets worse once one starts using MVar (A,B,C,...), or MVar [A]. So, the solution is: choose wisely! ;-) Regards, Roberto Zunino.

Thanks, you make some interesting points to consider. This leads me to
wonder how these arguments might be extended to
(1) IORef (a,b) vs. (IORef a, IORef b)
(2) TVar (a,b) vs. (TVar a, TVar b)
On 1/4/07, Roberto Zunino
Chad Scherrer wrote:
When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa?
No one is strictly better than the other. But there are practical implications of choosing between them.
For instance, MVar (A,B) is less prone to deadlock issues than (MVar A, MVar B). Consider
(a,b) :: (MVar A, MVar B)
alice = do takeMVar a ; takeMVar b ; foo ; putMVar a x ; putMVar b y bob = do takeMVar b ; takeMVar a ; bar ; putMVar b w ; putMVar a z
If alice and bob run concurrently, it might happen that alice takes a, bob takes b, and no one can proceed further. So, you must be very careful about the ordering of the takeMVar's (e.g. if you need both, always take a before taking b). There is no such issue using MVar (A,B), since only a single takeMVar is needed.
On the other hand using MVar (A,B) may reduce concurrency, imposing unnecessary locks. If alice2 only needs a, why should she be blocked from bob2 using only b? This issue gets worse once one starts using MVar (A,B,C,...), or MVar [A].
So, the solution is: choose wisely! ;-)
Regards, Roberto Zunino.
-- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

Hello Chad, Friday, January 5, 2007, 6:15:34 PM, you wrote:
Thanks, you make some interesting points to consider. This leads me to wonder how these arguments might be extended to
(1) IORef (a,b) vs. (IORef a, IORef b)
depends on whether you need to read/write both variables at the same or different moments. also, "IORef a" may be optimized to "IOURef a" which works faster
(2) TVar (a,b) vs. (TVar a, TVar b)
i never worked with STM, but guess that TVar usage pattern is just the smae as for MVar btw, you can use type synonym to make switching from IORef to MVar easier: type MyVar a = IORef a -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Do you need to maintain invariants that span the two? Put
operationally, do you want different threads to be able to access a
and b concurrently?
-m
"Chad Scherrer"
When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks!
--
Chad Scherrer
"Time flies like an arrow; fruit flies like a banana" -- Groucho Marx _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Not that I've worked through yet. I really could be using IORef for
now, but I started using MVar because I might start using multiple
threads at some point, and I'd like to get comfortable with MVars for
that time.
On 1/4/07, Mike Gunter
Do you need to maintain invariants that span the two? Put operationally, do you want different threads to be able to access a and b concurrently?
-m
"Chad Scherrer"
writes: When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks! Chad Scherrer
participants (4)
-
Bulat Ziganshin
-
Chad Scherrer
-
Mike Gunter
-
Roberto Zunino