Excerpts from Felipe Almeida Lessa's message of Sun Jul 24 22:02:36 -0400 2011:

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 =).

That's correct. resurrectThreads is called after garbage collection on the list of threads found to be garbage. Each of these threads will be woken up and sent a signal: BlockedOnDeadMVar if the thread was blocked on an MVar, or NonTermination if the thread was blocked on a Black Hole. Cheers, Edward

On Sun, Jul 24, 2011 at 10:02 PM, Felipe Almeida Lessa wrote:

On Sun, Jul 24, 2011 at 7:56 PM, Brandon Simmons 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 'threadDelay': 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 performGC 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.

On Tue, Jul 26, 2011 at 1:25 AM, Edward Z. Yang wrote:

Hello Brandon,

The answer is subtle, and has to do with what references are kept in code, which make an object considered reachable.  Essentially, the main thread itself keeps the MVar live while it still has forking to do, so that it cannot get garbage collected and trigger these errors.

Ah, okay. That seems like an obvious explanation for the exceptions to be raised at the same time in the forked threads.

Here is a simple demonstrative program:

   main = do        lock <- newMVar ()        forkIO (takeMVar lock)        forkIO (takeMVar lock)        forkIO (takeMVar lock)

(snip)

But in the meantime (esp. between invocation 2 and 3), the MVar cannot be garbage collected, because it is live on the stack.

Could GHC have been more clever in this case?  Not in general, since deciding whether or not a reference will actually be used or not boils down to the halting problem.

   loop = threadDelay 100 >> loop -- prevent blackholing from discovering this    main = do        lock <- newEmptyMVar        t1 <- newEmptyMVar        forkIO (takeMVar lock >> putMVar t1 ())        forkIO (loop `finally` putMVar lock ())        takeMVar t1

Maybe we could do something where MVar references are known to be writer ends or read ends, and let the garbage collector know that an MVar with only read ends left is a deadlocked one.  However, this would be a very imprecise analysis, and would not help in your original code (since all of your remaining threads had the possibility of writing to the MVar: it doesn't become clear that they can't until they all hit their takeMVar statements.)

I think this is the crux of what I was confused about. I had assumed read vs. write was being taken into account by the runtime in raising BlockedIndefinitelyOnMVar. This makes it obvious: loop = threadDelay 100 >> loop -- prevent blackholing from discovering this main = do lock <- newEmptyMVar forkIO (loop `finally` takeMVar lock) takeMVar lock Given that, I still can't say I understand what is happening in my original code. I'll try to work out an even simpler example on my own. Thanks for the thoughtful response, Brandon

Cheers, Edward