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 <eugene.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 <mukeshtiwari.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
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>



--
Best,
Eugene Perederey


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