On 27/07/2010, at 11:24 PM, Jean-Marie Gaillourdet wrote:
I've been trying to use repa and stumbled into rather strange behavior of my program. Sometimes, there seems to be a deadlock at other times it seems there is a livelock. Now, I've managed to prepare a version which consistently generates the following output:
$ ./MDim MDim: thread blocked indefinitely in an MVar operation $
But I don't use any MVar directly. And the only used library which is not part of ghc are repa and repa-algorithms. To state it clearly I don't use any MVars, par, pseq, forkIO nor any other parallelism or cuncurrency functionality. The only thing my program uses is repa which is supposed to use some kind of parallelism as far as the documentation says. So I am wondering whether this is a problem with my code or with repa or with ghc.
This is a symptom of not having calls to "force" in the right place. Suppose you've created a thunk that sparks of a parallel computation. If if some other parallel computation tries to evaluate it, then you've got nested parallelism. Operationally, it means that there was already a "gang" of threads doing something, but you tried to create a new one. The error message is poor, and we should really document it on the wik. However, if you get this message then the program should still give the correct result. If it's really deadlocking then it's a bug.
I'd be really happy if anyone could give me a hint how to debug this, or whether I am able to do anything about it, at all.
You'll want to add more calls to "force" to ensure that appropriate intermediate arrays are in manifest form. Using seq and deepSeqArray can also help. BTW: The Hackage repa package runs about 10x slower than it should against the current head, due to some changes in the inliner. I'm updating the package over the next few days, and I can also have a go at your example. Ben.