ANN: stm-chans: Additional types of channels for STM.
-------------------------------------------- -- stm-chans 1.0.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. In particular it offers these types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. This combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for some API improvements still making their way into the stm package[1]. These new functions include: * tryReadTChan :: TChan a -> STM (Maybe a) A version of readTChan which does not retry. Instead it returns Nothing if no value is available. * peekTChan :: TChan a -> STM a Get the next value from the TChan without removing it, retrying if the channel is empty. * tryPeekTChan :: TChan a -> STM (Maybe a) A version of peekTChan which does not retry. Instead it returns Nothing if no value is available. [1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/15507 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren
Wren,
Glad to see someone is doing a more complete packaging of STM helpers
and derivatives!
I've done a little work on bounded TChans[1] (hackage "bounded-tchan"
package) and I think you should consider a few things:
1) Split the reader counter and writer counters as I've done in
bounded-tchan. This gives 2-5 times better performance (I benchmarked
using Criterion, a single reader, a single writer, and tested channels
with bounds of 10, 100, and 1000 elements).
2) Implement a "tryWriteTBChan" for obvious reasons.
3) Implement a "sizeOfTBChan". This would require an extra word to
store the max size in addition to the counter (vs what you have of a
single counter counting down from the maximum toward zero), but the
use of {-# UNPACK #-} should keep it to a single extra word.
4) Help me figure out a good way to build dupTBChan [2]. It's not easy.
Feel free to copy any of my code if you find it useful, just leave an
authorship note. I'm interested if you have any ideas for dupping, we
could meet for coffee if it gets too clumsy to hash out over e-mail.
Cheers,
Thomas
[1] http://hackage.haskell.org/package/bounded-tchan
[2] http://stackoverflow.com/questions/5446484/how-to-add-a-finalizer-on-a-tvar
On Sun, Apr 3, 2011 at 8:35 PM, wren ng thornton
-------------------------------------------- -- stm-chans 1.0.0 --------------------------------------------
The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. In particular it offers these types:
* Control.Concurrent.STM.TBChan: Bounded FIFO channels.
When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly.
* Control.Concurrent.STM.TMChan: Closeable FIFO channels.
This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well.
* Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels.
This combines the capabilities of TBChan and TMChan.
In addition, the stm-chans package offers a (partial) compatibility layer for some API improvements still making their way into the stm package[1]. These new functions include:
* tryReadTChan :: TChan a -> STM (Maybe a)
A version of readTChan which does not retry. Instead it returns Nothing if no value is available.
* peekTChan :: TChan a -> STM a
Get the next value from the TChan without removing it, retrying if the channel is empty.
* tryPeekTChan :: TChan a -> STM (Maybe a)
A version of peekTChan which does not retry. Instead it returns Nothing if no value is available.
[1] http://article.gmane.org/gmane.comp.lang.haskell.libraries/15507
-------------------------------------------- -- Links --------------------------------------------
Homepage: http://code.haskell.org/~wren/
Hackage: http://hackage.haskell.org/package/stm-chans
Darcs: http://community.haskell.org/~wren/stm-chans
Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans
-- Live well, ~wren
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 4/3/11 11:58 PM, Thomas DuBuisson wrote:
Wren, Glad to see someone is doing a more complete packaging of STM helpers and derivatives!
I've done a little work on bounded TChans[1] (hackage "bounded-tchan" package) and I think you should consider a few things:
Ah, somehow I missed that in my searching. I'll give it a look and try to integrate things.
1) Split the reader counter and writer counters as I've done in bounded-tchan. This gives 2-5 times better performance (I benchmarked using Criterion, a single reader, a single writer, and tested channels with bounds of 10, 100, and 1000 elements).
That's crazy. I wonder why... must be a contention issue...
2) Implement a "tryWriteTBChan" for obvious reasons.
Good idea.
4) Help me figure out a good way to build dupTBChan [2]. It's not easy.
I've yet to figure out a way of doing this that has the right semantics. Perhaps splitting the reader and writer counters will help, though it sounds like you haven't had much luck either.
[2] http://stackoverflow.com/questions/5446484/how-to-add-a-finalizer-on-a-tvar
Have you taken a look at TwilightSTM? http://proglang.informatik.uni-freiburg.de/projects/syncstm/ http://hackage.haskell.org/package/twilight-stm Since I'm aiming to have stm-chans eventually incorporated into stm proper, that wouldn't work for me, though it sounds like it might solve the ideological question about adding finalizers to TVars -- Live well, ~wren
1) Split the reader counter and writer counters as I've done in bounded-tchan. This gives 2-5 times better performance (I benchmarked using Criterion, a single reader, a single writer, and tested channels with bounds of 10, 100, and 1000 elements).
That's crazy. I wonder why... must be a contention issue...
Exactly - contention between the reader and writer doesn't exist for non-bounded tchans. Splitting the reader and writer counter removes the contention on the counter except in the rare case the writer counter hits the bound. Admittedly, my benchmark was tailored to this issue - the change won't help when the contention is between multiple readers or multiple writers.
4) Help me figure out a good way to build dupTBChan [2]. It's not easy.
I've yet to figure out a way of doing this that has the right semantics. Perhaps splitting the reader and writer counters will help, though it sounds like you haven't had much luck either.
I know what I want to do, but GHC just can't :-(. Short of that solution, I don't think dupping will make it into bounded-tchan.
Have you taken a look at TwilightSTM?
http://proglang.informatik.uni-freiburg.de/projects/syncstm/ http://hackage.haskell.org/package/twilight-stm
No, but I will. Thanks for the links. Cheers, Thomas
participants (2)
-
Thomas DuBuisson -
wren ng thornton