14. Concurrency

Share by communicating

Go encourages a different approach in which shared values are passed around on channels and, in fact, NEVER actively shared by separate threads of execution.
Only one goroutine has access to the value at any given time.
Data races cannot occur, by design.

Do not communicate by sharing memory; instead, share memory by communicating.

Unix pipelines fit this model perfectly.

Goroutines

A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.
It is lightweight, costing little more than the allocation of stack space.
And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

go list.Sort() // run list.Sort concurrently; don't wait for it.

The effect is similar to the Unix shell’s & notation for running a command in the background.

Function literals are closures: the implementation makes sure the variables referred to by the function survive as long as they are active.

Channels

ci := make(chan int)            // unbuffered channel of integers
cj := make(chan int, 0)         // unbuffered or synchronous channel of integers
cs := make(chan *os.File, 100)  // buffered channel of pointers to Files

Unbuffered channels combine communication with synchronization—guaranteeing that two calculations (goroutines) are in a known state.

c := make(chan int)  // Allocate a channel.
// Start the sort in a goroutine; when it completes, signal on the channel.
go func() {
    list.Sort()
    c <- 1  // Send a signal; value does not matter.
}()
doSomethingForAWhile()
<-c   // Wait for sort to finish; discard sent value.

A buffered channel can be used like a semaphore, for instance to limit throughput.

Channels of channels

One of the most important properties of Go is that a channel is a first-class value that can be allocated and passed around like any other.

demultiplexing

Parallelization

Another application of these ideas is to parallelize a calculation across multiple CPU cores.

• an expensive operation to perform on a vector of items
• the value of the operation on each item is independent ```go type Vector []float64

// Apply the operation to v[i], v[i+1] … up to v[n-1]. func (v Vector) DoSome(i, n int, u Vector, c chan int) { for ; i < n; i++ { v[i] += u.Op(v[i]) } c <- 1 // signal that this piece is done }

const numCPU = runtime.NumCPU() // var numCPU = runtime.GOMAXPROCS(0)

func (v Vector) DoAll(u Vector) { c := make(chan int, numCPU) // Buffering optional but sensible. for i := 0; i < numCPU; i++ { go v.DoSome(ilen(v)/numCPU, (i+1)len(v)/numCPU, u, c) } // Drain the channel. for i := 0; i < numCPU; i++ { <-c // wait for one task to complete } // All done. }

<br />
---
<a name="MZXIO"></a>
## A leaky buffer
The tools of concurrent programming can even make** non-concurrent** ideas easier to express.
**a leaky bucket free list**<br />To avoid allocating and freeing buffers, it keeps a free list, and uses a buffered channel to represent it.
```go
var freeList = make(chan *Buffer, 100)
var serverChan = make(chan *Buffer)
func client() {
    for {
        var b *Buffer
        // Grab a buffer if available; allocate if not.
        select {
        case b = <-freeList:
            // Got one; nothing more to do.
        default:
            // None free, so allocate a new one.
            b = new(Buffer)
        }
        load(b)              // Read next message from the net.
        serverChan <- b      // Send to server.
    }
}

The server loop receives each message from the client, processes it, and returns the buffer to the free list.

func server() {
    for {
        b := <-serverChan    // Wait for work.
        process(b)
        // Reuse buffer if there's room.
        select {
        case freeList <- b:
            // Buffer on free list; nothing more to do.
        default:
            // Free list full, just carry on.
        }
    }
}