Select statement nuances

I read about select statements and its execution steps but I'm not fully understanding what's happening here.

I created two examples of a Fan-In function (from the Go Concurrency Patterns talk)

The first one:

select {
case value := <-g1:
	c <- value
case value := <-g2:
	c <- value
}

Prints from each channel as expected (each channel keeps its own counter):

Bob  : 0
Alice: 0
Bob  : 1
Alice: 1
Bob  : 2
Alice: 2
Alice: 3
Alice: 4
Bob  : 3
Alice: 5

The second one:

select {
case c <- <-g1:
case c <- <-g2:
}

It is randomly selecting a channel and discarding the other one's value:

Bob  : 0
Alice: 1
Alice: 2
Alice: 3
Bob  : 4
Alice: 5
Bob  : 6
Alice: 7
Alice: 8
Bob  : 9

Update: while writing this question, I thought the second select was equal to:

var v string
select {
case v = <-g1:
case v = <-g2:
	c <- v
}

But I was wrong, because this one always prints from the second channel (<strike>as expected from a switch like statement</strike> because there isn't fallthrough in select statements):

Bob  : 0
Bob  : 1
Bob  : 2
Bob  : 3
Bob  : 4
Bob  : 5
Bob  : 6
Bob  : 7
Bob  : 8
Bob  : 9

Does someone understand why my second example creates a sequence?

Thanks,

Your second select statement is interpreted as:

v1 := <-g1
v2 := <-g2
select {
case c <- v1:
case c <- v2:
}

As described in the language spec, the RHS of each send operator will be evaluated up front when the statement is executed:

> Execution of a "select" statement proceeds in several steps:
>
> 1. For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement. The result is a set of channels to receive from or send to, and the corresponding values to send. Any side effects in that evaluation will occur irrespective of which (if any) communication operation is selected to proceed. Expressions on the left-hand side of a RecvStmt with a short variable declaration or assignment are not yet evaluated.
> 2. If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection. Otherwise, if there is a default case, that case is chosen. If there is no default case, the "select" statement blocks until at least one of the communications can proceed.
> 3. ...

So as step (1) both <-g1 and <-g2 will be evaluated, receiving values from each channel. This may block if there is nothing to receive yet.

At (2), we wait until c is ready to send a value and then randomly choose a branch of the select statement to execute: since they are both waiting on the same channel, they are both ready to proceed.

This explains the behaviour you saw where values are dropped and you got non-deterministic behaviour in which value was sent to c.

If you want to wait on g1 and g2, you will need to use the first form for your statement as you've discovered.

According to [http://golang.org/ref/spec] The Go Programming Language Specification

for {  // send random sequence of bits to c
	select {
	case c <- 0:  // note: no statement, no fallthrough, no folding of cases
	case c <- 1:
	}
}

It'll generate 0 or 1 randomly.

For the second exaple

select {
case c <- <-g1:
case c <- <-g2:
}

when g1 has Bob : 0 and g2 has Alice: 0, either c <- <-g1 or c <- <-g2 will execute , but only one will.

That explain why you have the sequence 0 1 2 3 4 5 6 7 8 9 but not 0 0 1 1 2 2 3 3 4 4

And it also say:

in source order, upon entering the "select" statement. The result is a set of channels to receive from or send to, and the corresponding values to send.

According to my comprehension , even if c <- <-g1 will execute , Alice: 0 also will pop up from g2. So every time you have Bob : i and Alice: i, only one will be printed out.