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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
