CS452 - Real-Time Programming - Fall 2009

Lecture 34 - Go

Go

For more comprehensive information: Go here, or here.

Make programming fun again.

No new major systems language in a decade

Even though:

sprawling libraries & dependency chains
dominance of networking
client/server focus
massive clusters
multi-core CPUs

Go is a response to these challenges

Objectives

Safety: type-safe and memory-safe.
Good support for concurrency and communication.
Efficient, latency-free garbage collection.
High-speed compilation.

Fundamentals

Clean, concise syntax.
Lightweight type system.
Strict separation of interface and implementation.

Run-time support

Garbage collection.
Strings, maps, communication channels
Concurrency.

Package model

Explicit dependencies to enable faster builds.

Channels

var c chan string; 
c = make(chan string); 
c <- "Hello"; // infix send 

// in a different goroutine 

greeting := <-c; // prefix receive 
cc := new(chan chan string); // cc a variable of type channel providing channels of type string
cc <- c; // handing off a capability

Goroutines

func wrapper(a int, c chan int) {
    result := longCalculation(a);
    c <- result;
}

c := make(chan int);
go wrapper(17, c);

// do something for a while; then...
x := <-c;

Implementing data-flow in Go

Go has channels as first class objects, just as Occam does.

Here is an example that puts into a channel the natural numbers 2, 3, ...
ch is a variable of type chan with a `protocol' which is the type int
The <- operator puts i into ch.
- Blocking occurs only if the channel buffer is full.
- (The size of the buffer can be stipulated on instantiation.)

    func generate(ch chan int) { 
        for i := 2; ; i++ { 
            ch <- i  // Send 'i to channel 'ch'.
        }         
    }

Here is another example that gets numbers from one channel and sends some of them to another.

The caller of these functions must pass the channels into the functions.
The same operator , <-, gets an int from the channel for the assignment to i.

    func filter(in, out chan int, prime int) {
        for {
            i := <-in;  // Receive value of new variable 'i' from 'in'.
            if i % prime != 0 {
                out <- i  // Send 'i' to channel 'out'.
            }
        }
    }

These two functions should execute simultaneously like processes joined by a Unix pipe.

Putting generate and filter together shows how goroutines get a common channel for communication.

generate is created and will start putting natural numbers into ch.
In the for loop, main grabs the first number from ch (2), and prints it.
It then makes another channel and passes the two channels to filter along with the first prime (2).
filter gets the subsequent numbers from generate and passes those not divisible by 2 to ch1.
ch1 is assigned to ch and the first number out of filter (3) is the new prime.
A second filter goroutine is instantiated removing numbers divisible by 3.
And so on

Note that we are here creating a set of goroutines that gives a data-flow computation.

We only need blocking for input.
We saw the equivalent when we talked, long ago, about producer/consumer.

    func main() {
          ch := make(chan int);  // Create a new channel.
          go generate(ch);  // Start generate() as a goroutine.
          for {
                prime := <-ch;
                fmt.Println(prime);
                ch1 := make(chan int);
                go filter(ch, ch1, prime);
                ch = ch1
          }
    }

Making a server in Go

A server listens for a request then replies with the result.

The reply is handled by having the client give a reply channel as part of the request
```
    type request struct {
        a, b    int;
        replyc  chan int;
    }
```

The server sits in a FOREVER loop waiting for input on its service request channel

    func server(service chan *request, quit chan bool) {
        for {
            select {
                case req := <-service:
                    go worker(req);  // don't wait for it
                case <-quit:
                    return;
       }
    }

It then creates a worker to do the work, passing on the request including the channel for replying.

The worker does the work

    func worker(req *request) {
         req.replyc <- req.a + req.b;
    }

Requests can be replied to out of order.

Here is a different way to start the server, a function that

instantiates the server, and
returns the channel on which it receives requests

    func startServer( ) chan *request {
       req := make( chan *request );
       quit := make( chan bool );
       go server( req, quit );
       return req;
    }

And here is the server in action
- We first start the server.
- We then formulate a bunch of requests, including a reply channel for each.
- The requests are put into the service channel.
  - Notice that we must retain at least the identity of each reply channel.
- After all the requests have been sent out the replies are obtained from each reply channel
```
    func main() {
        adder := startServer( );
        const N = 100;
        var reqs [N]request;
        for i := 0; i < N; i++ {
            req := &reqs[i];
            req.a = i;
            req.b = i + N;
            req.replyc = make(chan int);
            adder <- req;
        }
        for i := N-1; i >= 0; i-- {   // doesn't matter what order
            if <-reqs[i].replyc != N + 2*i {
                fmt.Println("fail at", i);
            }
        }
        fmt.Println("done");
    }
```
Making the client start the server hides a little complexity here.
- If main started the clients as goroutines it would be necessary to pass the service request channel to each

The description of the Go memory model goes into the details of synchronization: it is educational in the context of cs452.

Return to: