[ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency.
Hi cafe, For the past few months I've been working on a library for concurrency testing in Haskell, which I'll be giving a talk on at the Haskell Symposium next week. Now it's on Hackage! --- Déjà Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC’s regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it’s not just big concurrent programs that are hard, small ones are too. We as programmers just don’t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn’t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. ## How to use it: If you’re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That’s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour, except for CRef, the IORef equivalent, where modifyCRef behaves like atomicModifyIORef, not modifyIORef. There are some other differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can’t (except for the IO instance). --- There is a blog post with references to prior posts and related papers here: http://www.barrucadu.co.uk/posts/2015-08-27-announce-dejafu.html -- Michael Walker (http://www.barrucadu.co.uk)
Why not keep the original names? If it is a drop in replacement, wouldn't it be best to just have a flag in cabal depend on dejafu for testing and just recompile. The various *-compat could provide inspiration. Sorry if I'm missing the point... Michał Original Message From: Michael Walker Sent: Thursday, August 27, 2015 9:30 AM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] [ANN] dejafu-0.1.0.0: Overloadable primitives for testable, potentially non-deterministic, concurrency. Hi cafe, For the past few months I've been working on a library for concurrency testing in Haskell, which I'll be giving a talk on at the Haskell Symposium next week. Now it's on Hackage! --- Déjà Fu is a library for developing and testing concurrent Haskell programs, it provides a typeclass-abstraction over GHC’s regular concurrency API, allowing the concrete implementation to be swapped out. Why do we need this? Well, concurrency is really hard to get right. Empirical studies have found that many real-world concurrency bugs can be exhibited with small test cases using as few as two threads: so it’s not just big concurrent programs that are hard, small ones are too. We as programmers just don’t seem to have a very good intuition for traditional threads-and-shared-memory-style concurrency. The typical approach to testing concurrent programs is to just run them lots of times, but that doesn’t provide any hard coverage guarantees, and then we need to wonder: how many runs do we need? Fortunately, there has been a lot of research into testing concurrency in the past several years. Systematic concurrency testing is an approach where the source of nondeterminism, the actual scheduler, is swapped out for one under the control of the testing framework. This allows possible schedules to be systematically explored, giving real coverage guarantees for our tests. This is a library implementing systematic concurrency testing. It provides two typeclasses, MonadConc to abstract over much of Control.Concurrent and related modules, and MonadSTM, to similarly abstract over Control.Monad.STM. ## How to use it: If you’re not making use of any IO in your code other than for concurrency, the transition to using MonadConc and MonadSTM will probably just be a textual substitution: - IO is replaced with MonadConc m => m - STM with MonadSTM m => m - *IORef with *CRef - *MVar with *CVar - *TVar with *CTVar - Most other things have the same name, and so can be replaced by just swapping imports around. If you are using other IO, you will need a gentle sprinkling of MonadIO and liftIO in your code as well. ## Is this really just a drop-in replacement for IO/STM? That’s the idea, yes. More specifically, the IO instance of MonadConc and the STM instance of MonadSTM just use the regular IO and STM functions, and so should have no noticeable change in behaviour, except for CRef, the IORef equivalent, where modifyCRef behaves like atomicModifyIORef, not modifyIORef. There are some other differences which can lead to incorrect results when testing, but which should not affect code when used in an IO or STM context. Specifically: Control.Monad.Conc.Class.getNumCapabilities can lie to encourage more concurrency when testing; and Control.Exception.catch can catch exceptions from pure code, but Control.Monad.Conc.Class.catch can’t (except for the IO instance). --- There is a blog post with references to prior posts and related papers here: http://www.barrucadu.co.uk/posts/2015-08-27-announce-dejafu.html -- Michael Walker (http://www.barrucadu.co.uk)
Actually that's a good suggestion! The differing names for the mutable variable types is a holdover from when my approach was different: I started out thinking I was going to make something like the Par monad, but with multiple-write variables. The only issue would be picking module names to avoid conflicts, but that's hardly an insurmountable problem. On 27/08/15 at 10:42am, mantkiew@gsd.uwaterloo.ca wrote:
Why not keep the original names? If it is a drop in replacement, wouldn't it be best to just have a flag in cabal depend on dejafu for testing and just recompile. The various *-compat could provide inspiration.
Sorry if I'm missing the point...
Michał
-- Michael Walker (http://www.barrucadu.co.uk)
participants (2)
-
mantkiew＠gsd.uwaterloo.ca -
Michael Walker