Channels in Go

Channel Introduction

Channel Types and Values

1. chan T denotes a bidirectional channel type. Compilers allow both receiving values from and sending values to bidirectional channels.
2. chan<- T denotes a send-only channel type. Compilers don't allow receiving values from send-only channels.
3. <-chan T denotes a receive-only channel type. Compilers don't allow sending values to receive-only channels.

Channel Value Comparisons

Channel Operations

1. Close the channel by using the following function call

   close(ch)
   

   where close is a built-in function. The argument of a close function call must be a channel value, and the channel ch must not be a receive-only channel.
2. Send a value, v, to the channel by using the following syntax

   ch <- v
   

   where v must be a value which is assignable to the element type of channel ch, and the channel ch must not be a receive-only channel. Note that here <- is a channel-send operator.
3. Receive a value from the channel by using the following syntax

   <-ch
   

   A channel receive operation always returns at least one result, which is a value of the element type of the channel, and the channel ch must not be a send-only channel. Note that here <- is a channel-receive operator. Yes, its representation is the same as a channel-send operator.
   For most scenarios, a channel receive operation is viewed as a single-value expression. However, when a channel operation is used as the only source value expression in an assignment, it can result a second optional untyped boolean value and become a multi-value expression. The untyped boolean value indicates whether or not the first result is sent before the channel is closed. (Below we will learn that we can receive unlimited number of values from a closed channel.)
   Two channel receive operations which are used as source values in assignments:

   v = <-ch
   v, sentBeforeClosed = <-ch
   

4. Query the value buffer capacity of the channel by using the following function call

   cap(ch)
   

   where cap is a built-in function which has ever been introduced in containers in Go. The return result of a cap function call is an int value.
5. Query the current number of values in the value buffer (or the length) of the channel by using the following function call

   len(ch)
   

   where len is a built-in function which also has ever been introduced before. The return value of a len function call is an int value. The result length is the number of elements which have already been sent successfully to the queried channel but haven't been received (taken out) yet.

Detailed Explanations for Channel Operations

1. nil channels.
2. non-nil but closed channels.
3. not-closed non-nil channels.

1. Closing a nil or an already closed channel produces a panic in the current goroutine.
2. Sending a value to a closed channel also produces a panic in the current goroutine.
3. Sending a value to or receiving a value from a nil channel makes the current goroutine enter and stay in blocking state for ever.

1. the receiving goroutine queue (generally FIFO). The queue is a linked list without size limitation. Goroutines in this queue are all in blocking state and waiting to receive values from that channel.
2. the sending goroutine queue (generally FIFO). The queue is also a linked list without size limitation. Goroutines in this queue are all in blocking state and waiting to send values to that channel. The value (or the address of the value, depending on compiler implementation) each goroutine is trying to send is also stored in the queue along with that goroutine.
3. the value buffer queue (absolutely FIFO). This is a circular queue. Its size is equal to the capacity of the channel. The types of the values stored in this buffer queue are all the element type of that channel. If the current number of values stored in the value buffer queue of the channel reaches the capacity of the channel, the channel is called in full status. If no values are stored in the value buffer queue of the channel currently, the channel is called in empty status. For a zero-capacity (unbuffered) channel, it is always in both full and empty status.

1. If the value buffer queue of the channel is not empty, in which case the receiving goroutine queue of the channel must be empty, the goroutine R will receive (by shifting) a value from the value buffer queue. If the sending goroutine queue of the channel is also not empty, a sending goroutine will be shifted out of the sending goroutine queue and resumed to running state again. The value that the just shifted sending goroutine is trying to send will be pushed into the value buffer queue of the channel. The receiving goroutine R continues running. For this scenario, the channel receive operation is called a non-blocking operation.
2. Otherwise (the value buffer queue of the channel is empty), if the sending goroutine queue of the channel is not empty, in which case the channel must be an unbuffered channel, the receiving goroutine R will shift a sending goroutine from the sending goroutine queue of the channel and receive the value that the just shifted sending goroutine is trying to send. The just shifted sending goroutine will get unblocked and resumed to running state again. The receiving goroutine R continues running. For this scenario, the channel receive operation is called a non-blocking operation.
3. If value buffer queue and the sending goroutine queue of the channel are both empty, the goroutine R will be pushed into the receiving goroutine queue of the channel and enter (and stay in) blocking state. It may be resumed to running state when another goroutine sends a value to the channel later. For this scenario, the channel receive operation is called a blocking operation.

1. If the receiving goroutine queue of the channel is not empty, in which case the value buffer queue of the channel must be empty, the sending goroutine S will shift a receiving goroutine from the receiving goroutine queue of the channel and send the value to the just shifted receiving goroutine. The just shifted receiving goroutine will get unblocked and resumed to running state again. The sending goroutine S continues running. For this scenario, the channel send operation is called a non-blocking operation.
2. Otherwise (the receiving goroutine queue is empty), if the value buffer queue of the channel is not full, in which case the sending goroutine queue must be also empty, the value the sending goroutine S trying to send will be pushed into the value buffer queue, and the sending goroutine S continues running. For this scenario, the channel send operation is called a non-blocking operation.
3. If the receiving goroutine queue is empty and the value buffer queue of the channel is already full, the sending goroutine S will be pushed into the sending goroutine queue of the channel and enter (and stay in) blocking state. It may be resumed to running state when another goroutine receives a value from the channel later. For this scenario, the channel send operation is called a blocking operation.

1. If the receiving goroutine queue of the channel is not empty, in which case the value buffer of the channel must be empty, all the goroutines in the receiving goroutine queue of the channel will be shifted one by one, each of them will receive a zero value of the element type of the channel and be resumed to running state.
2. If the sending goroutine queue of the channel is not empty, all the goroutines in the sending goroutine queue of the channel will be shifted one by one and each of them will produce a panic for sending on a closed channel. This is the reason why we should avoid concurrent send and close operations on the same channel. In fact, when the go command's data race detector option (-race) is enabled, concurrent send and close operation cases might be detected at run time and a runtime panic will be thrown.

1. If the channel is closed, both its sending goroutine queue and receiving goroutine queue must be empty, but its value buffer queue may not be empty.
2. At any time, if the value buffer is not empty, then its receiving goroutine queue must be empty.
3. At any time, if the value buffer is not full, then its sending goroutine queue must be empty.
4. If the channel is buffered, then at any time, at least one of the channel's goroutine queues must be empty (sending, receiving, or both).
5. If the channel is unbuffered, most of the time one of its sending goroutine queue and the receiving goroutine queue must be empty, with one exception. The exception is that a goroutine may be pushed into both of the two queues when executing a select control flow code block.

Some Channel Use Examples

package main

import (
	"fmt"
	"time"
)

func main() {
	c := make(chan int) // an unbuffered channel
	go func(ch chan<- int, x int) {
		time.Sleep(time.Second)
		// <-ch    // fails to compile
		// Send the value and block until the result is received.
		ch <- x*x // 9 is sent
	}(c, 3)
	done := make(chan struct{})
	go func(ch <-chan int) {
		// Block until 9 is received.
		n := <-ch
		fmt.Println(n) // 9
		// ch <- 123   // fails to compile
		time.Sleep(time.Second)
		done <- struct{}{}
	}(c)
	// Block here until a value is received by
	// the channel "done".
	<-done
	fmt.Println("bye")
}

9
bye

package main

import "fmt"

func main() {
	c := make(chan int, 2) // a buffered channel
	c <- 3
	c <- 5
	close(c)
	fmt.Println(len(c), cap(c)) // 2 2
	x, ok := <-c
	fmt.Println(x, ok) // 3 true
	fmt.Println(len(c), cap(c)) // 1 2
	x, ok = <-c
	fmt.Println(x, ok) // 5 true
	fmt.Println(len(c), cap(c)) // 0 2
	x, ok = <-c
	fmt.Println(x, ok) // 0 false
	x, ok = <-c
	fmt.Println(x, ok) // 0 false
	fmt.Println(len(c), cap(c)) // 0 2
	close(c) // panic!
	// The send will also panic if the above
	// close call is removed.
	c <- 7
}

package main

import (
	"fmt"
	"time"
)

func main() {
	var ball = make(chan string)
	kickBall := func(playerName string) {
		for {
			fmt.Println(<-ball, "kicked the ball.")
			time.Sleep(time.Second)
			ball <- playerName
		}
	}
	go kickBall("John")
	go kickBall("Alice")
	go kickBall("Bob")
	go kickBall("Emily")
	ball <- "referee" // kick off
	var c chan bool   // nil
	<-c               // blocking here for ever
}

Channel Element Values Are Transferred by Copy

About Channel and Goroutine Garbage Collections

Channel Send and Receive Operations Are Simple Statements

package main

import (
	"fmt"
	"time"
)

func main() {
	fibonacci := func() chan uint64 {
		c := make(chan uint64)
		go func() {
			var x, y uint64 = 0, 1
			for ; y < (1 << 63); c <- y { // here
				x, y = y, x+y
			}
			close(c)
		}()
		return c
	}
	c := fibonacci()
	for x, ok := <-c; ok; x, ok = <-c { // here
		time.Sleep(time.Second)
		fmt.Println(x)
	}
}

for-range on Channels

for v := range aChannel {
	// use v
}

for {
	v, ok = <-aChannel
	if !ok {
		break
	}
	// use v
}

	for x := range c {
		time.Sleep(time.Second)
		fmt.Println(x)
	}

select-case Control Flow Code Blocks

• No expressions and statements are allowed to follow the select keyword (before {).
• No fallthrough statements are allowed to be used in case branches.
• Each statement following a case keyword in a select-case code block must be either a channel receive operation or a channel send operation statement. A channel receive operation can appear as the source value of a simple assignment statement. Later, a channel operation following a case keyword will be called a case operation.
• If there are one or more non-blocking case operations, Go runtime will randomly select one of these non-blocking operations to execute, then continue to execute the corresponding case branch.
• If all the case operations in a select-case code block are blocking operations, the default branch will be selected to execute if the default branch is present. If the default branch is absent, the current goroutine will be pushed into the corresponding sending goroutine queue or receiving goroutine queue of every channel involved in all case operations, then enter blocking state.

package main

import "fmt"

func main() {
	var c chan struct{} // nil
	select {
	case <-c:             // blocking operation
	case c <- struct{}{}: // blocking operation
	default:
		fmt.Println("Go here.")
	}
}

package main

import "fmt"

func main() {
	c := make(chan string, 2)
	trySend := func(v string) {
		select {
		case c <- v:
		default: // go here if c is full.
		}
	}
	tryReceive := func() string {
		select {
		case v := <-c: return v
		default: return "-" // go here if c is empty
		}
	}
	trySend("Hello!") // succeed to send
	trySend("Hi!")    // succeed to send
	// Fail to send, but will not block.
	trySend("Bye!")
	// The following two lines will
	// both succeed to receive.
	fmt.Println(tryReceive()) // Hello!
	fmt.Println(tryReceive()) // Hi!
	// The following line fails to receive.
	fmt.Println(tryReceive()) // -
}

package main

func main() {
	c := make(chan struct{})
	close(c)
	select {
	case c <- struct{}{}:
		// Panic if the first case is selected.
	case <-c:
	}
}

The Implementation of the Select Mechanism

1. evaluate all involved channel expressions and value expressions to be potentially sent in case operations, from top to bottom and left to right. Destination values for receive operations (as source values) in assignments needn't be evaluated at this time.
2. randomize the branch orders for polling in step 5. The default branch is always put at the last position in the result order. Channels may be duplicate in the case operations.
3. sort all involved channels in the case operations to avoid deadlock (with other goroutines) in the next step. No duplicate channels stay in the first N channels of the sorted result, where N is the number of involved channels in the case operations. Below, the channel lock order is a concept for the first N channels in the sorted result.
4. lock (a.k.a., acquire the locks of) all involved channels by the channel lock order produced in last step.
5. poll each branch in the select block by the randomized order produced in step 2:
   1. if this is a case branch and the corresponding channel operation is a send-value-to-closed-channel operation, unlock all channels by the inverse channel lock order and make the current goroutine panic. Go to step 12.
   2. if this is a case branch and the corresponding channel operation is non-blocking, perform the channel operation and unlock all channels by the inverse channel lock order, then execute the corresponding case branch body. The channel operation may wake up another goroutine in blocking state. Go to step 12.
   3. if this is the default branch, then unlock all channels by the inverse channel lock order and execute the default branch body. Go to step 12.

   (Up to here, the default branch is absent and all case operations are blocking operations.)
6. push (enqueue) the current goroutine (along with the information of the corresponding case branch) into the receiving or sending goroutine queue of the involved channel in each case operation. The current goroutine may be pushed into the queues of a channel for multiple times, for the involved channels in multiple cases may be the same one.
7. make the current goroutine enter blocking state and unlock all channels by the inverse channel lock order.
8. wait in blocking state until other channel operations wake up the current goroutine, ...
9. the current goroutine is waken up by another channel operation in another goroutine. The other operation may be a channel close operation or a channel send/receive operation. If it is a channel send/receive operation, there must be a case channel receive/send operation (in the current being explained select-case block) cooperating with it (by transferring a value). In the cooperation, the current goroutine will be dequeued from the receiving/sending goroutine queue of the channel.
10. lock all involved channels by the channel lock order.
11. dequeue the current goroutine from the receiving goroutine queue or sending goroutine queue of the involved channel in each case operation,
    1. if the current goroutine is waken up by a channel close operation, go to step 5.
    2. if the current goroutine is waken up by a channel send/receive operation, the corresponding case branch of the cooperating receive/send operation has already been found in the dequeuing process, so just unlock all channels by the inverse channel lock order and execute the corresponding case branch.

12. done.

1. a goroutine may stay in the sending goroutine queues and the receiving goroutine queues of multiple channels at the same time. It can even stay in the sending goroutine queue and the receiving goroutine queue of the same channel at the same time.
2. when a goroutine currently being blocked at a select-case code block gets resumed later, it will be removed from all the sending goroutine queues and the receiving goroutine queues of all channels involved in the channel operations following case keywords in the select-case code block.

More