Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them
Hi, I've recently noticed unGetChan and isEmptyChan have been deprecated as a result of these two bug reports: http://hackage.haskell.org/trac/ghc/ticket/3527 http://hackage.haskell.org/trac/ghc/ticket/4154 I was working on an alternative implementation of concurrent channels (concurrent streams) to use as a building block for FRP and thought while I'm at it I'd have a go at fixing the problem with concurrent channels. I've attached the files for a reimplementation of concurrent channels, 2 implementations of lower-level concurrent queues, one that only supports non-blocking reads, and another that supports both blocking and non-blocking reads, and an implementation of concurrent streams. The reimplementation of concurrent channels is built on top of the blocking queue. The streams are built on top of the non-blocking queue and have Functor and Applicative instances. The reimplementation of concurrent channels passes the two tests in the bug reports above. I haven't run further tests though. The logic for how the channel operations are supposed to proceed is summarized in Chan.hs. Due to an extra lock this implementation is likely a bit slower than the old implementation. One assumption that has been made is that IORef reads and writes are atomic. In other words that if there are two or more concurrent writes to the same IORef, one of them will successfully write its data to it. I have not been able to find exact semantics of IORefs though I've asked in #haskell and others have suggested that the assumption is valid. Proposal: 1) split concurrent channels from base into a separate library of higher level concurrency primitives 2) add concurrent queues to the library of higher level concurrency primitives 3) replace concurrent channels with the new implementation based on concurrent queues 4) add concurrent streams to the library of higher level concurrency primitives I was in a bit of a rush to write this up and post the code after finding out that the new Haskell platform will be released this month though it seems unlikely this would go in at this point - probably for the best as the code hasn't been tested much. I'm also not sure if concurrent streams would be more appropriate on Hackage? Thoughts and comments appreciated. Deadline: 8th of June. Ivan
On 5/7/12 11:25 AM, Ivan Tomac wrote:
One assumption that has been made is that IORef reads and writes are atomic. In other words that if there are two or more concurrent writes to the same IORef, one of them will successfully write its data to it. I have not been able to find exact semantics of IORefs though I've asked in #haskell and others have suggested that the assumption is valid.
I'm sure reads and writes are atomic (for safety reasons), though I don't know if that's formally specified anywhere. It should be though. If you're paranoid, you can always use atomicModifyIORef which guarantees atomicity. Albeit, that's more powerful (and hence slower) than you need for plain reads and writes. -- Live well, ~wren
On 5/7/12 11:25 AM, Ivan Tomac wrote:
Proposal: 1) split concurrent channels from base into a separate library of higher level concurrency primitives 2) add concurrent queues to the library of higher level concurrency primitives 3) replace concurrent channels with the new implementation based on concurrent queues 4) add concurrent streams to the library of higher level concurrency primitives
If you do break off a separate library (or resolve the bugs to everyone's satisfaction), to the extent possible it'd be nice to see non-STM versions of stm-chans[1] provided. I'd be willing to help out with that over the summer, though it certainly won't make it into this month's HP. [1] http://hackage.haskell.org/package/stm-chans/ -- Live well, ~wren
participants (2)
-
Ivan Tomac -
wren ng thornton