Thanks for all your responses, folks. I'm curious about swapping to a single channel and will try that.
On Friday, April 7, 2017 at 4:37:10 PM UTC-6, John Souvestre wrote: > > A few ideas… > > > > Instead of using two channels, use just one. Let the writer(s) use a > “select” to do the write, else default to doing a read (then loop to try > the write again). I believe that would accomplish what you are doing now > but with less overhead. > > > > I think that it’s great that you implemented this with channels first. If > you need more throughput then I’d think mutexes next, and atomics as a last > resort. > > > > Perhaps using an array as a circular buffer with read and write accesses > synchronized by mutexes would be a good next step. > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com <javascript:> [mailto: > golan...@googlegroups.com <javascript:>] *On Behalf Of *Eno Compton > *Sent:* 2017 April 06, Thu 23:29 > *To:* golang-nuts > *Subject:* [go-nuts] Writing a non-blocking thread-safe buffer > > > > 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...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- 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.
