Re: Proposal: To add 2 new lower-level concurrency constructs and rebuild Concurrent.Chan using them
Just had a few hours of sleep and think perhaps I sent that email out too soon. I forgot what my original intention was and just ended up submitting a proposal. The original question I had was what would be the best way to proceed with something like this? Have it submitted as a patch for Control.Concurrent.Chan with the concurrent queues added in? Or put it up on Hackage? Fixing concurrent channels and submitting this at all was sort of an afterthought but it just made sense to build them on top of the queues. Maybe Hackage is a better place for this until it's better tested in any case. Ivan
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
On 5/8/12 3:56 AM, Ivan Tomac wrote:
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.
Sure. I was just pointing out the paranoia option ;)
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.
I was meaning more that some folks might be concerned about the slowdown compared to the current implementation. Which we should really quantify before replacing the old implementation. If it's significant, I'm fine with having different implementations based on whether you're performance crazy vs need those features.
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?
Sounds like a good plan. Let me know if you want any help with the bounded and closeable variants, or with benchmarking. -- Live well, ~wren
On 07/05/2012 22:11, Ivan Tomac wrote:
Just had a few hours of sleep and think perhaps I sent that email out too soon. I forgot what my original intention was and just ended up submitting a proposal.
The original question I had was what would be the best way to proceed with something like this? Have it submitted as a patch for Control.Concurrent.Chan with the concurrent queues added in? Or put it up on Hackage?
Fixing concurrent channels and submitting this at all was sort of an afterthought but it just made sense to build them on top of the queues.
Maybe Hackage is a better place for this until it's better tested in any case.
These kinds of data structures are fiendishly hard to get right, as we know from bitter experience. I'm not suggesting that your implementation is wrong in any way - but it's hard to tell whether it is right. For instance, are you sure that it is robust to asynchronous exceptions? I think to replace Chan we would need at the very least plenty of tests. I realise this might sound a bit hypocritical given that we never had many tests for Chan, and we've discovered a number of bugs in it over the years, but it's a "devil you know" argument. Let's be sure we're not making anything worse. Personally speaking, I'm not keen on the overly point-free style in your code, which I find hard to read. Again you can take this as my opinion if you want, but I think STM is the way forward. Correctness is *far* easier, and performance is surprisingly good (and we could improve it if necessary). If you're avoiding STM for performance reasons, show me the numbers. Cheers, Simon
participants (3)
-
Ivan Tomac -
Simon Marlow -
wren ng thornton