4 ms·

The preference of channel size being unbuffered or just 1 is interesting. That seems like something specific to a problem domain; for instance, in projects I a

The preference of channel size being unbuffered or just 1 is interesting. That seems like something specific to a problem domain; for instance, in projects I am working on now, having a large buffered channel (1000s deep) is useful for worker queues of thousands of goroutines, that all read from a task feeder channel. This type of queuing seems go-idiomatic, and negates the need for additional synchronization. In this case, the backpressure blocking on writers is a feature.

baby 7y ago
Maybe to avoid deadlocks?
fishywang 7y ago
Why having a 1000s buffered channel is useful in this case? If it's unbuffered, you still get the backpressure blocking on writers as a feature, since you have a worker queues of thousands of goroutines to read and handle them.
- palebluedot 7y ago
  That's a good point, at steady-state, I'd imagine unbuffered channels would have the same throughput as a deeply buffered channels. The main advantage is being able to spool up faster and smooth out throughput, but it could be for most workloads that is not valuable enough. Perhaps I placed too much value on that. Your comment (and others) have convinced me to do some more empirical testing and see how necessary buffered channels are for my goal.
dallbee 7y ago
A lot of my coworkers were getting hung up on this point too. I think they're just emphasizing that large channel buffers can hide concurrency problems, so you want to be careful when using them. The last sentence in the recommendation emphasizes this: use them with scrutiny.
Matthias247 7y ago
Picking a queue size is a latency/throughput/determinism tradeoff. Picking a higher queue size can increase the peak throughput. The queue will smoothen out peaks and valleys in the workload, and the other end of the queue will get rarer into situations where there is no work. If you know the duration of the "valleys" in your workload you can size your queue exactly to get over them. However a too big queue size can easily lead to higher latencies. In extreme situations the work might be already outdated at the point of time it's processed by the receiver. And backpressure on the producer is less given. Queue sizes > 1 can also mask concurrency issues (like deadlocks), which will then only show up rarely in production when the queue is fully exhausted. I guess that's one of the main reasons why they picked the 0/1 rule.

baby 7y ago

Maybe to avoid deadlocks?

fishywang 7y ago

Why having a 1000s buffered channel is useful in this case? If it's unbuffered, you still get the backpressure blocking on writers as a feature, since you have a worker queues of thousands of goroutines to read and handle them.

palebluedot 7y ago
That's a good point, at steady-state, I'd imagine unbuffered channels would have the same throughput as a deeply buffered channels. The main advantage is being able to spool up faster and smooth out throughput, but it could be for most workloads that is not valuable enough. Perhaps I placed too much value on that. Your comment (and others) have convinced me to do some more empirical testing and see how necessary buffered channels are for my goal.

dallbee 7y ago

A lot of my coworkers were getting hung up on this point too. I think they're just emphasizing that large channel buffers can hide concurrency problems, so you want to be careful when using them. The last sentence in the recommendation emphasizes this: use them with scrutiny.

Matthias247 7y ago

Picking a queue size is a latency/throughput/determinism tradeoff. Picking a higher queue size can increase the peak throughput. The queue will smoothen out peaks and valleys in the workload, and the other end of the queue will get rarer into situations where there is no work. If you know the duration of the "valleys" in your workload you can size your queue exactly to get over them. However a too big queue size can easily lead to higher latencies. In extreme situations the work might be already outdated at the point of time it's processed by the receiver. And backpressure on the producer is less given. Queue sizes > 1 can also mask concurrency issues (like deadlocks), which will then only show up rarely in production when the queue is fully exhausted. I guess that's one of the main reasons why they picked the 0/1 rule.