A Tour of Go のChannelsについて

Question

A Tour of GoのChannelsについての質問です。
デフォルトのコードを実行すると
-5 17 12
という出力結果が得られるのですが、channelに返される順番としてなぜこの順番になるのでしょうか？配列の前半を引数として実行した関数が最初に処理されて、先に書いたxの方に結果が渡ると思ったのですが、結果は予想と逆でした。

また、次のようにコードを改変して実行したら、
4 9 -1 12
という出力になりました。channelはスタックになっているのかと思ったのですが、そうではありませんでした。channelが返される順番はどのように決定されるのでしょうか。

package main

import "fmt"

func sum(s []int, c chan int) {
	sum := 0
	for _, v := range s {
		sum += v
	}
	c <- sum // send sum to c
}

func main() {
	s := []int{7, 2, 8, -9, 4, 0}

	c := make(chan int)
	go sum(s[:len(s)/3], c)
	go sum(s[len(s)/3:len(s)*2/3], c)
	go sum(s[len(s)*2/3:], c)
	x, y, z := <-c, <-c, <-c// receive from c

	fmt.Println(x, y, z, x+y+z)
}

Answer 1

chanはメッセージキューなのでFIFO（先入先出）と呼ばれる挙動になります。
スタックはLIFO（後入先出）と呼ばれる挙動です。

ただし、質問にあるコードの場合、順番が入れ替わってもおかしくないかもしれません。
（順番が維持される保証のない記述なので）

追記

以下のコードを何度も手元で実行した出力を下に貼ります。
https://play.golang.org/p/udCf_zvmaF3

package main

import "fmt"

func hey(n int, c chan int) {
	fmt.Println("hey:", n)
	c <- n
}
func main() {
	c := make(chan int)
	fmt.Println("setup")
	go hey(1, c)
	go hey(2, c)
	go hey(3, c)
	fmt.Println("started")
	x, y, z := <-c, <-c, <-c // receive from c

	fmt.Println(x, y, z, x+y+z)
}

出力結果

$ go run .
setup
started
hey: 3
hey: 2
hey: 1
3 2 1 6
$ go run .
setup
started
hey: 3
hey: 1
hey: 2
3 1 2 6

goステートメントが３行を通り抜けてからhey関数が呼ばれることがわかります。
そして、このように実行のたびに実行される順番が異なっていることが確認できます。
つまり、goroutineの準備が完了した状態で次にgoroutineスイッチが起こる時
待機しているgoroutine群のどれが起動するのかは不定つまりランダムです。

このような挙動はある種狙って組み込まれています。

複数のgoroutineがあるチャネルからの取り出しを待っている状態で一つだけ値をそのチャネルに書き込んだ場合、
どのチャネルの取り出し待ちが発火するかはランダムです。

ランダムにする理由は仕事をするgoroutineを分散させるという狙いがあります。
（特定のgoroutineだけ働いている状態を回避する）

x, y, z := <-c, <-c, <-c

ここは最初ｘだけがチャネルからの取り出し待ちになります。
ｘが値を受け取ったらyがチャネルからの取り出し待ちになります。
ｙが値を受け取ったら最後にzがチャネルからの取り出し待ちになります。
ここはシーケンシャルに処理されることは保証されるということです。
（３行に分けて書いても同様です）

Comments

[mask_mus]

上の行に書いたものから順にキューに入っていくと思っていたのですが、行の順番は関係ないのでしょうか？キューに入る順番はどのようにして決まるのでしょうか？

[nobonobo]

chanに投げ込んだ順番の通りに取り出しされるのは保証されますが、質問のコードはchanに投げ込まれる順番は予想と異なることがありうる書き方になってます。

[mask_mus]

自分なりに考察した結果、s[len(s)/3:len(s)*2/3]等のインデックスの処理時間と、sum関数内のループ処理速度の差によって順番と異なるのではないかと考えたのですか、どのくらい合っているのでしょうか？出来れば、なぜ予想と異なる順番になってしまうのかを教えていただきたいです。

[nobonobo]

処理内容によってチャネルへの書き込みに到達する時間が異なるという考えは正しいですが、

それよりも３つ程度のgoroutineセットアップは
実際のgoroutineの処理を開始するまでもなく準備完了してしまいますので、

その後３つのgoroutineのいずれかが起動しますが、
走る準備を終えた３つのgoroutineが実際の処理を開始する順番は保証されません。

[nobonobo]

実例を追記しました。