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