Brandon Michael Moore wrote:
On Wed, Feb 14, 2007 at 10:04:32AM +0000, Simon Marlow wrote:
Perhaps I'm missing something, but doesn't GHC already detect the kind of
deadlock you're talking about here? When a thread is blocked and cannot be
woken up, it is sent the BlockedOnDeadMVar exception. It's more precise
than the extension you propose, because the GC is used to check which
threads are unreachable and therefore cannot be woken up, so it can detect
mutual-deadlock between two threads in a system that contains other running
threads.
Perhaps the idea is specifically to detect from the outside when a group of
threads is deadlocked, maybe like something that can be done with computation
spaces in Oz, definitely like the way tree spaces work in Aardappel
( http://wouter.fov120.com/aardappel/ ).
Based on your description, it sounds like it wouldn't work very well to have
a parent thread waiting on a channel, with one of the child threads set up
to catch BlockedOnDeadMVar and send a message, lest the parent thread be
considered deadlocked and sent BlockedOnDeadMVar itself.
Yes, that would be a problem. You can force a thread to stay alive using
mkStablePtr on the ThreadId, or alternatively the parent thread can catch
BlockedOnDeadMVar and ignore it. Neither of these solutions is particularly
nice, I agree.
What are the semantics of the exception? It seems like it might be tricky
to provide any guarantees, if a thread can catch the exception and make the
MVar live again.
A thread certainly can catch the exception and continue: the fact that the MVar
was not reachable during GC doesn't mean it has been garbage collected, the GC
is only being used to detect reachability in this case. I'm pretty sure you
could specify precisely what GHC does, but it's not trivial because you'd need
to build a concept of reachability into the semantics.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
