2010/2/16 Neil Brown
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