Hi Wren, wren ng thornton<wren at freegeek.org> 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: http://www.haskell.org/pipermail/libraries/2012-May/017782.html 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? Ivan