2010/2/16 Neil Brown <nc...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
