Understanding behavior of BlockedIndefinitelyOnMVar exception

Brandon Simmons brandon.m.simmons at gmail.com
Mon Jul 25 22:05:39 CEST 2011

On Sun, Jul 24, 2011 at 10:02 PM, Felipe Almeida Lessa
<felipe.lessa at gmail.com> wrote:
> On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons
> <brandon.m.simmons at gmail.com> wrote:
>> What I think I've learned here is that the BlockedIndefinitelyOnMVar
>> exception is raised in all the blocked threads "at once" as it were.
>> That despite the fact that the handler code in 'lockPrint' restores
>> the lock for successive threads.
>> This would also seem to imply that putMVar's in an exception handler
>> don't stop the runtime from raising the BlockedIndefinitelyOnMVar. But
>> that doesn't really seem right.
> Does anything change if you somehow force a GC sometime after "good2"?
>  Perhaps with some calculation generating garbage, perhaps with
> performGC.  IIRC, the runtime detects BlockedIndefinitelyOnMVar on GC.
>  But I'm probably wrong =).

Here is a variation that calls 'performGC' after the first thread is
forked. It prints the exception simultaneously right before  the last

main2 = do
    lock <- newMVar ()
    forkIO $ lockPrint "good1" lock

    threadDelay 1000000
    forkIO $ badLockPrint "bad" lock

    -- these both raise blocked indefinitely exception
    threadDelay 1000000
    forkIO $ lockPrint "good2" lock
    threadDelay 1000000
    forkIO $ lockPrint "good3" lock

    threadDelay 1000000

Perhaps laziness is confusing the issue as well?

Thanks and sorry for the delayed response,
Brandon Simmons

> Cheers,
> --
> Felipe.

More information about the Glasgow-haskell-users mailing list