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: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] 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+unsubscr...@googlegroups.com.
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.

Reply via email to