[Haskell-cafe] RFC: concurrent-extra
Roel van Dijk
vandijk.roel at gmail.com
Wed Feb 17 03:56:42 EST 2010
2010/2/16 Neil Brown <nccb2 at kent.ac.uk>:
> I had a look at the code for Event (both versions) and Lock (but not the
> others just yet) and it seemed fine. If you do lots of calls to waitTimeout
> before a set you will accumulate old locks in the list, but that won't cause
> any error that I can see, so it would only be a problem in pathological
I think I can fix the garbage locks on waitTimeout by tupling each
lock with the ThreadId of the thread that created it. When a timeout
occurs I can then simply remove the unnecessary lock from the list.
The extra overhead would be the construction of a tuple and acquiring
a ThreadId each time you wait for an event.
> I'm not sure there is a good way to test MVar algorithms. One way to do it
> (which the Concurrent Haskell Debugger did online, IIRC:
> http://www.informatik.uni-kiel.de/~fhu/chd/) is to reimplement IO to explore
> different interleavings of the various MVar calls to look for deadlocks. If
> you're testing STM, generally you can look to capture invariants of your
> transactions and check that they hold after each transaction (e.g. that if
> the state is Set, there shouldn't be any locks waiting with an event).
Interesting. It reminds me of Wouter Swierstra's recent paper "Beauty
in the Beast":
More information about the Haskell-Cafe