channels/

README

Channels

Channels allow goroutines to communicate with each other through the use of signaling semantics. Channels accomplish this signaling through the use of sending/receiving data or by identifying state changes on individual channels. Don't architect software with the idea of channels being a queue, focus on signaling and the semantics that simplify the orchestration required.

Design Guidelines

Channel Design

Channels allow goroutines to communicate with each other through the use of signaling semantics. Channels accomplish this signaling through the use of sending/receiving data or by identifying state changes on individual channels. Don't architect software with the idea of channels being a queue, focus on signaling and the semantics that simplify the orchestration required.

Language Mechanics:

• Use channels to orchestrate and coordinate goroutines.
  • Focus on the signaling semantics and not the sharing of data.
  • Signaling with data or without data.
  • Question their use for synchronizing access to shared state.
    • There are cases where channels can be simpler for this but initially question.
• Unbuffered channels:
  • Receive happens before the Send.
  • Benefit: 100% guarantee the signal being sent has been received.
  • Cost: Unknown latency on when the signal will be received.
• Buffered channels:
  • Send happens before the Receive.
  • Benefit: Reduce blocking latency between signaling.
  • Cost: No guarantee when the signal being sent has been received.
    • The larger the buffer, the less guarantee.
    • Buffer of 1 can give you one delayed send of guarantee.
• Closing channels:
  • Close happens before the Receive. (like Buffered)
  • Signaling without data.
  • Perfect for signaling cancellations and deadlines.
• NIL channels:
  • Send and Receive block.
  • Turn off signaling
  • Perfect for rate limiting or short-term stoppages.

Design Philosophy:

Depending on the problem you are solving, you may require different channel semantics. Depending on the semantics you need, different architectural choices must be taken.

• If any given Send on a channel CAN cause the sending goroutine to block:
  • Be careful with Buffered channels larger than 1.
    • Buffers larger than 1 must have reason/measurements.
  • Must know what happens when the sending goroutine blocks.
• If any given Send on a channel WON'T cause the sending goroutine to block:
  • You have the exact number of buffers for each send.
    • Fan Out pattern
  • You have the buffer measured for max capacity.
    • Drop pattern
• Less is more with buffers.
  • Don’t think about performance when thinking about buffers.
  • Buffers can help to reduce blocking latency between signaling.
    • Reducing blocking latency towards zero does not necessarily mean better throughput.
    • If a buffer of one is giving you good enough throughput then keep it.
    • Question buffers that are larger than one and measure for size.
    • Find the smallest buffer possible that provides good enough throughput.

Diagrams

Guarantee Of Delivery

The Guarantee Of Delivery is based on one question: “Do I need a guarantee that the signal sent by a particular goroutine has been received?”

Signaling With Or Without Data

When you are going to signal with data, there are three channel configuration options you can choose depending on the type of guarantee you need.

Signaling without data serves the main purpose of cancellation. It allows one goroutine to signal another goroutine to cancel what they are doing and move on. Cancellation can be implemented using both unbuffered and buffered channels.

State

The behavior of a channel is directly influenced by its current State. The state of a channel can be nil, open or closed.

Links

• Channel Communication
• Share Memory By Communicating - Andrew Gerrand
• The Nature Of Channels In Go - William Kennedy
• A Retrospective on SEDA - Matt Welsh
• Understanding Channels - Kavya Joshi

Code Review

• Basic mechanics (Go Playground)
• Tennis game (Go Playground)
• Race
• Unbuffered w/ guarantees
• Program timeout
• Parallel link checker

Advanced Code Review

• Channel communication ordering (Go Playground)

Exercises

Exercise 1

Write a program where two goroutines pass an integer back and forth ten times. Display when each goroutine receives the integer. Increment the integer with each pass. Once the integer equals ten, terminate the program cleanly.

• Template (Go Playground) |
• Answer (Go Playground)

Exercise 2 (*)

Write a program that uses a fan out pattern to generate 100 random numbers concurrently. Have each goroutine generate a single random number and return that number to the main goroutine over a buffered channel. Set the size of the buffer channel so no send ever blocks. Don't allocate more buffers than you need. Have the main goroutine display each random number it receives and then terminate the program.

• Template (Go Playground) |
• Answer (Go Playground)

Exercise 3

Write a program that generates up to 100 random numbers concurrently. Do not send all 100 values so the number of sends/receives is unknown.

• Template (Go Playground) |
• Answer (Go Playground)

Exercise 4 (*)

Write a program that generates up to 100 random numbers concurrently using a worker pool. Reject even values. Instruct the workers to shutdown with 100 odd numbers have been collected.

• Template (Go Playground) |
• Answer (Go Playground)

---

All material is licensed under the Apache License Version 2.0, January 2004.