I added a few prints to your code fun m = do putStrLn "fun1" putMVar m 10 putStrLn "fun2" main = do m <- newEmptyMVar forkIO $ fun m putStrLn "main1" putMVar m 10 putStrLn "main2" It works 50/50 for me in Mac OS X 10.6.8. On 4 September 2012 12:16, mukesh tiwari wrote:

Hi Eugene Thank you for reply.

On Wed, Sep 5, 2012 at 12:32 AM, Eugene Perederey wrote:

...

Why do you think main should block more than once? I see only two possible scenarios: the fun thread puts to mvar first thus blocking main,

So at least in this case I should get thread blocked indefinitely in an MVar operation

...

or 10 is put into mvar in main, blocking the other thread indefinitely.

or main will execute and fun thread will die. There are 50 - 50 chance for this ( assuming both are equally likely ). I did some modification in my code and Now I am consistently getting "Concurrent: thread blocked indefinitely in an MVar operation"

import Data.List import Control.Concurrent

fun m = do putMVar m 10 return ()

main = do m <- newEmptyMVar forkIO $ fun m putStrLn "I am inside main"

putMVar m 10 return ()

[mukesh.tiwari@ Programming]$ ghc-7.4.1 -threaded -fforce-recomp Concurrent.hs [1 of 1] Compiling Main ( Concurrent.hs, Concurrent.o ) Linking Concurrent ... [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

[mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

[mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

[mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

[mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

My question is why the outcome in first case is deterministic. Every time the code executing ( at least half the time main thread should be blocked ) .

Regards Mukesh Tiwari

...

On 4 September 2012 11:54, mukesh tiwari wrote:

...

Hello All I was going trough Real World Haskell and it says "If we try to put a value into an MVar that is already full, our thread is put to sleep until another thread takes the value out". I wrote a simple code to block main

import Data.List import Control.Concurrent

fun m = do putMVar m 10 return ()

main = do m <- newEmptyMVar forkIO $ fun m putMVar m 10 return ()

What I am expecting that main should be blocked at least couple of times but its behaving more deterministically. [mukesh.tiwari@ Programming]$ ghc-7.4.1 -threaded -fforce-recomp Concurrent.hs [1 of 1] Compiling Main ( Concurrent.hs, Concurrent.o ) Linking Concurrent ... [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$

I am expecting to get thread blocked indefinitely on MVar at least half the time. Could some one please tell me why this deterministic behavior ? Regards Mukesh Tiwari

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- Best, Eugene Perederey

-- Best, Eugene Perederey

There's no basis on which to assume both alternative schedules are equally likely. I would guess that, in your first example, there's enough start-up cost for a new thread that the main thread consistently gets to its putMVar first, whereas in the second example, main is waylaid with its putStrLn, allowing the forked thread to get there first consistently. Dean At 12:46 AM +0530 9/5/12, mukesh tiwari wrote:

Hi Eugene Thank you for reply.

On Wed, Sep 5, 2012 at 12:32 AM, Eugene Perederey <mailto:eugene.perederey@gmail.comeugene.perederey@gmail.com> wrote:

Why do you think main should block more than once? I see only two possible scenarios: the fun thread puts to mvar first thus blocking main,

So at least in this case I should get thread blocked indefinitely in an MVar operation

or 10 is put into mvar in main, blocking the other thread indefinitely.

or main will execute and fun thread will die. There are 50 - 50 chance for this ( assuming both are equally likely ). I did some modification in my code and Now I am consistently getting "Concurrent: thread blocked indefinitely in an MVar operation"

import Data.List import Control.Concurrent

fun m = do putMVar m 10 return ()

main = do m <- newEmptyMVar forkIO $ fun m putStrLn "I am inside main" putMVar m 10 return ()

[mukesh.tiwari@ Programming]$ ghc-7.4.1 -threaded -fforce-recomp Concurrent.hs [1 of 1] Compiling Main ( Concurrent.hs, Concurrent.o ) Linking Concurrent ... [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 I am inside main Concurrent: thread blocked indefinitely in an MVar operation

My question is why the outcome in first case is deterministic. Every time the code executing ( at least half the time main thread should be blocked ) .

Regards Mukesh Tiwari

On 4 September 2012 11:54, mukesh tiwari <mailto:mukeshtiwari.iiitm@gmail.commukeshtiwari.iiitm@gmail.com> wrote:

...

Hello All I was going trough Real World Haskell and it says "If we try to put a value into an MVar that is already full, our thread is put to sleep until another thread takes the value out". I wrote a simple code to block main

import Data.List import Control.Concurrent

fun m = do putMVar m 10 return ()

main = do m <- newEmptyMVar forkIO $ fun m putMVar m 10 return ()

What I am expecting that main should be blocked at least couple of times but its behaving more deterministically. [mukesh.tiwari@ Programming]$ ghc-7.4.1 -threaded -fforce-recomp Concurrent.hs [1 of 1] Compiling Main ( Concurrent.hs, Concurrent.o ) Linking Concurrent ... [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$ ./Concurrent +RTS -N2 [mukesh.tiwari@ Programming]$

I am expecting to get thread blocked indefinitely on MVar at least half the time. Could some one please tell me why this deterministic behavior ? Regards Mukesh Tiwari

...

_______________________________________________ Beginners mailing list mailto:Beginners@haskell.orgBeginners@haskell.org

http://www.haskell.org/mailman/listinfo/beginnershttp://www.haskell.org/mailman/listinfo/beginners

-- Best, Eugene Perederey

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners