ANN: stm-chans: Additional types of channels for STM.

[Thomas DuBuisson]

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