5 comments

[ 5.8 ms ] story [ 349 ms ] thread
I'd be interested in having someone with more knowledge of Go look at what I'm doing in the Go code and see if I'm missing something. Either way, I'm pretty happy with this implementation in C#.
I took a quick look at your code. Iadmit my C++ is getting rusty. And I haven't programmed Go in a while. I was familiar with Go's channel implement as well has its predecessors in Plan9 and Newsqueak. In part because I have done an implementation with the Stackless module of PyPy. The two problems I see are: 1) you don't implement the select algorithm. 2) Go channels where implemented to handle multiple CPUs. In a simple example, this is overhead for Go. With the asynchronous queue I am not sure if you are obeying Go's channel's rendezvous semantics. I also suspect Go's results may be different and closer to what you are doing if you used go channels with buffers.
Go channels aren't as fast as they could/should be. Folks do go the mutex route when they need the extra speed.

My C# is non existent but if you get the WaitGroup concept (I may have missed it) in there as well this could be a handy package.

Thanks for the responses, both of you. I'll have a look at WaitGroup and Select. The C# solution does support multiple cores by virtue of its use of Task.
The select algorithm is described in Robert Pike's "The Implementation of Newsqueak." You may want to take a look at a paper called "Scalable Join Patterns" which is about implementing Join Patterns in C#. Join patterns involve channels. The take-away of the "Scalable" paper is the use of lock-free algorithms.