I don't think using separate write/read channels do anything much here. If you are concerned goroutines reading the channel somehow slowing down the writes, you already have a goroutine that's doing the transfer on the other end.
On Friday, April 7, 2017 at 8:36:14 AM UTC-7, Eno Compton wrote: > > Hi All, > > I'm trying to write a non-blocking thread-safe buffer for use in a high > throughput system. In short, I want to create a buffer that decouples the > speed of writes from that of reads. > > For a first attempt, using channels in the implementation seems best. Here > is a link <https://play.golang.org/p/d01uanEjbN> to the current > implementation. I have a write channel and a buffered read channel. As an > intermediary between the two channels, I spin off a goroutine on > initialization of the buffer which constantly pulls values off the write > channel and attempts to put them on to the read channel. If the read > channel is full, I discard a value from the read channel before inserting > the new value. > > This implementation works. What I seek to do now is improve the throughput > of the buffer. I understand doing so requires proper benchmarking and > measuring. What I'm curious about though is the experience of others on > this list. In systems which require high throughput, am I best suited > sticking with channels? Would atomics be an appropriate design choice? What > about mutexes? > > Forgive me if this question seems naive. I'm new to Go and am still > developing a sense for the language. > > Thanks, > > Eno > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
