[Haskell-cafe] RFC: concurrent-extra

[Roel van Dijk]

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
> cases.

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":
http://www.cs.nott.ac.uk/~txa/publ/beast.pdf

Thanks,
Roel