Strange GHC/STM behaviour
mlesniak at uni-kassel.de
Mon Mar 15 04:59:54 EDT 2010
In one of my example programs I have a strange behaviour: it is a very
simple taskpool using STM; in pseudocode it's
1. generate data structures
2. initialize data structures
3. fork threads
4. wait (using STM) until the pool is empty and all threads are finished
5. print a final message
In very few cases, which depend on the number of threads spawned, the
program hangs *after* the final message of step 5 has been printed.
"Few cases" means, for example, 50.000 good, terminating runs before
it hangs. If you increment the number of spawned threads (to a few
hundred or thousands), it hangs much faster. Since forked threads
terminate after the main thread terminates (which it should after
printing the message), this behaviour is quite unexpected.
Since I've experienced strange behaviour in the past which was the
fault of my system configuration, I am a bit cautious before
reporting a bug on GHC's bugtracker, especially since its reproduction
is so difficult and random.
So my question is how much circumspection is expected/needed before
one should enter a bug in the bug tracker? I've tested the attached
code on three different systems (with different linux systems, but
always GHC 6.12.1 (since it's a bit costly to install the older
versions)) and observed the mentioned behaviour. Is this enough to
justify a bug report? Or, on the other hand, could someone spot the
error in the attached code. Given my history with strange parallel
behaviour, I am much more sure that it's the fault of my code, but I
can't spot the error and the described behaviour (halting *after* the
final message) is really strange.
Addendum: Daniel Fischer could reproduce the problem and pointed
out, that making the evaluation of the TVAR's value strict does not
reproduce the behaviour. This is even stranger in this context; I
don't see, how lazy evaluation can change the behaviour of my code.
Dipl.-Inf. Michael C. Lesniak
University of Kassel
Programming Languages / Methodologies Research Group
Department of Computer Science and Electrical Engineering
Wilhelmshöher Allee 73
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2580 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100315/a46beff2/Pool-0001.bin
More information about the Glasgow-haskell-users