Strange GHC/STM behaviour

[Michael Lesniak]

Hello,


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[1], 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[2], 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.

Cheers,
 Michael

[1] http://www.haskell.org/pipermail/haskell-cafe/2010-March/073938.html
[2] http://www.haskell.org/pipermail/haskell-cafe/2010-March/074520.html

-- 
Dipl.-Inf. Michael C. Lesniak
University of Kassel
Programming Languages / Methodologies Research Group
Department of Computer Science and Electrical Engineering

Wilhelmshöher Allee 73
34121 Kassel

Phone: +49-(0)561-804-6269
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pool.hs
Type: text/x-haskell
Size: 2580 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20100315/a46beff2/Pool-0001.bin