.GO File Format – Concurrency

Goroutines

GoStmt = "go" Expression .

A go statement starts a function or method call as an independent concurrent thread of control, a goroutine, in the same address space (spec: Go statements). The expression must be a call and cannot be parenthesised. The same built-in functions are restricted as for expression statements.

The function value and arguments are evaluated in the calling goroutine, as for an ordinary call, but the program does not wait for the call to finish. When the function ends, the goroutine ends, and any return values are discarded. When main returns, the program exits and other goroutines are not waited for.

go Server()
go func(ch chan<- bool) {
	for {
		sleep(10)
		ch <- true
	}
}(c)

Channels

A channel lets goroutines communicate by sending and receiving values of one element type. See Channel types for their syntax and direction rules. A channel may be used by any number of goroutines without further synchronisation. It acts as a first-in, first-out queue.

unbuffered := make(chan int)
buffered := make(chan int, 100)

buffered <- 1        // send
v := <-buffered      // receive
v, ok := <-buffered  // ok is false if the channel is closed and empty
close(buffered)

With capacity zero or absent, a channel is unbuffered: communication succeeds only when both sides are ready. Otherwise it is buffered: communication proceeds without blocking if the buffer is not full (sends) or not empty (receives).

• The two-value receive, x, ok := <-ch, gives ok == false when the value is a zero value produced because the channel is closed and empty.
• A close on a receive-only channel is a compile-time error.
• A for … range ch loop receives until the channel is closed; see Statements.

Select

SelectStmt = "select" "{" { CommClause } "}" .
CommClause = CommCase ":" StatementList .
CommCase   = "case" ( SendStmt | RecvStmt ) | "default" .
RecvStmt   = [ ExpressionList "=" | IdentifierList ":=" ] RecvExpr .
RecvExpr   = Expression .

A select statement chooses which of a set of send or receive operations proceeds (spec: Select statements). It runs in these steps:

1. For all the cases, the channel operands of receives, and the channel and value of sends, are evaluated exactly once, in source order, on entering. Side effects happen whichever case is chosen. Expressions on the left of a receive are not evaluated yet.
2. If any communications can proceed, one of them is chosen by a uniform pseudo-random selection. Otherwise a default case is chosen if there is one. If not, the statement blocks until a communication can proceed.
3. The chosen communication, unless it is the default, is performed.
4. If it was a receive with an assignment or short declaration, the left-hand expressions are evaluated and the values assigned.
5. The statement list of the chosen case runs.

select {
case i1 = <-c1:
	print("received ", i1, " from c1\n")
case c2 <- i2:
	print("sent ", i2, " to c2\n")
case i3, ok := <-c3:
	if ok {
		print("received ", i3, " from c3\n")
	} else {
		print("c3 is closed\n")
	}
default:
	print("no communication\n")
}

select {}  // block forever

A channel with a nil value can never proceed, so a select over only nil channels with no default blocks forever, and a break leaves the select, not an enclosing loop, unless labelled.

The memory model

The memory model says when a read of a variable in one goroutine is guaranteed to observe a write in another. It was revised in Go 1.19 to match the approach of C, C++, Java, JavaScript, Rust and Swift. Its advice is that programs that modify data accessed at the same time by several goroutines must serialise that access, using channels or other primitives such as sync and sync/atomic.

var c = make(chan int, 10)
var a string

func f() {
	a = "hello, world"
	c <- 0
}

func main() {
	go f()
	<-c
	print(a) // guaranteed to print "hello, world"
}

var limit = make(chan int, 3)

func main() {
	for _, w := range work {
		go func(w func()) {
			limit <- 1
			w()
			<-limit
		}(w)
	}
	select {}
}