Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them

Ivan Tomac ivan.tomac at
Tue May 8 09:56:55 CEST 2012

Hi Wren,

wren ng thornton<wren at>  wrote:
> 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.

I'd rather not use atomicModifyIORef - if IORef reads and writes
aren't atomic I could just use MVars. If IORefs are atomic though, I
would think that it's better to only use MVars where a lock would be
required and use IORefs otherwise.
It seems to me MVars have a fair bit of overhead over plain IORefs.

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

Thanks. I have already, as far as I can tell, fixed the bugs,
hopefully without introducing any new ones.
The code is attached to the original post:
It's possible it got stripped from the post by the mail client though?
Alright, so perhaps the way forward is to create a new library on
Hackage, and (eventually) remove concurrent channels from base?


More information about the Libraries mailing list