When to use a buffered channel?

Question

What are the uses cases for buffered channels ? If i want multiple parallel actions i could just use the default, synchronous channel eq.

package main
import         


        

Answer 1

To give a single, slightly-more-concrete use case:

Suppose you want your channel to represent a task queue, so that a task scheduler can send jobs into the queue, and a worker thread can consume a job by receiving it in the channel.

Suppose further that, though in general you expect each job to be handled in a timely fashion, it takes longer for a worker to complete a task than it does for the scheduler to schedule it.

Having a buffer allows the scheduler to deposit jobs in the queue and still remain responsive to user input (or network traffic, or whatever) because it does not have to sleep until the worker is ready each time it schedules a task. Instead, it goes about its business, and trusts the workers to catch up during a quieter period.

If you want an EVEN MORE CONCRETE example dealing with a specific piece of software then I'll see what I can do, but I hope this meets your needs.

Answer 2

Generally, buffering in channels is beneficial for performance reasons.

If a program is designed using an event-flow or data-flow approach, channels provide the means for the events to pass between one process and another (I use the term process in the same sense as in Tony Hoare's Communicating Sequential Processes (CSP), ie. effectively synonymous with the goroutine).

• There are times when a program needs its components to remain in lock-step synchrony. In this case, unbuffered channels are required.

• Otherwise, it is typically beneficial to add buffering to the channels. This should be seen as an optimisation step (deadlock may still be possible if not designed out).

• There are novel throttle structures made possible by using channels with small buffers (example).

• There are special overwriting or lossy forms of channels used in occam and jcsp for fixing the special case of a cycle (or loop) of processes that would otherwise probably deadlock. This is also possible in Go by writing an overwriting goroutine buffer (example).

You should never add buffering merely to fix a deadlock. If your program deadlocks, it's far easier to fix by starting with zero buffering and think through the dependencies. Then add buffering when you know it won't deadlock.

You can construct goroutines compositionally - that is, a goroutine may itself contain goroutines. This is a feature of CSP and benefits scalability greatly. The internal channels between a group of goroutines are not of interest when designing the external use of the group as a self-contained component. This principle can be applied repeatedly at increasingly-larger scales.

Answer 3

If the receiver of the channel is always slower than sender a buffer of any size will eventually be consumed. That will leave you with a channel that pauses your go routine as often as a unbuffered channel so you might as well use an unbuffered channel.

If the receiver is typically faster than the sender except for an occasional burst a buffered channel may be helpful and the buffer should be set to the size of the typical burst which you can arrive at by measurement at runtime.

As an alternative to a buffered channel it may better to just send an array or a struct containing an array over the channel to deal with bursts/batches.

Answer 4

Buffered channels are non-blocking for the sender as long as there's still room. This can increase responsiveness and throughput.

Sending several items on one buffered channel makes sure they are processed in the order in which they are sent.

From Effective Go (with example): "A buffered channel can be used like a semaphore, for instance to limit throughput."

In general, there are many use-cases and patterns of channel usage, so this is not an exhausting answer.

Answer 5

It's a hard question b/c the program is incorrect: It exits after receiving a signal from one goroutine, but three were started. Buffering the channel makes it no different.

EDIT: For example, here is a bit of general discussion about channel buffers. And some exercise. And a book chapter about the same.