CSP(Communicating Sequential Processes) channlesgoroutine 
GopherCon 2017
channel goroutine channel
golang goroutinechannel

channel 可以天然的实现了下面四个特性：

  • goroutine 安全
  • 在不同的 goroutine 之间存储和传输值 – 提供 FIFO 语义 (buffered channel 提供）
  • 可以让 goroutine block/unblock
channel

make chan

src/runtime/chan.go

其定义如下：

channel 
groutine goroutine

发送和接收

channel

还是以前面的任务队列为例：

其中 G1 是发送者，G2 是接收，因为 ch 是长度为 3 的带缓冲 channel，初始的时候 hchan 结构体的 buf 为空，sendx 和 recvx 都为 0，当 G1 向 ch 里发送数据的时候，会首先对 buf 加锁，然后将要发送的数据 copy 到 buf 里，并增加 sendx 的值，最后释放 buf 的锁。然后 G2 消费的时候首先对 buf 加锁，然后将 buf 里的数据 copy 到 task 变量对应的内存里，增加 recvx，最后释放锁。整个过程，G1 和 G2 没有共享的内存，底层通过 hchan 结构体的 buf，使用 copy 内存的方式进行通信，最后达到了共享内存的目的，这完全符合 CSP 的设计理念

Do not comminute by sharing memory;instead, share memory by communicating

一般情况下，G2 的消费速度应该是慢于 G1 的，所以 buf 的数据会越来越多，这个时候 G1 再向 ch 里发送数据，这个时候 G1 就会阻塞，那么阻塞到底是发生了什么呢？

Goroutine Pause/Resume

goroutine 是 Golang 实现的用户空间的轻量级的线程，有 runtime 调度器调度，与操作系统的 thread 有多对一的关系，相关的数据结构如下图：

其中 M 是操作系统的线程，G 是用户启动的 goroutine，P 是与调度相关的 context，每个 M 都拥有一个 P，P 维护了一个能够运行的 goutine 队列，用于该线程执行。

当 G1 向 buf 已经满了的 ch 发送数据的时候，当 runtine 检测到对应的 hchan 的 buf 已经满了，会通知调度器，调度器会将 G1 的状态设置为 waiting, 移除与线程 M 的联系，然后从 P 的 runqueue 中选择一个 goroutine 在线程 M 中执行，此时 G1 就是阻塞状态，但是不是操作系统的线程阻塞，所以这个时候只用消耗少量的资源。

那么 G1 设置为 waiting 状态后去哪了？怎们去 resume 呢？我们再回到 hchan 结构体，注意到 hchan 有个 sendq 的成员，其类型是 waitq，查看源码如下：

waiting 

runnable

wait empty channel

runtime G2 sudog

总结：

goroutine channel 
goroutine