Many issues, of course, but Go tries to take care of them. Channel send and receive are atomic. The select statement is very carefully defined and implemented, etc.

But goroutines run in shared memory, communication networks can deadlock, multithreaded debuggers suck, and so on.

Go gives you the primitives

Don’t program the way you would in C or C++ or even Java.

Channels give you synchronization and communication both, and that makes them powerful but also easy to reason about if you use them well.
The rule is:

Do not communicate by sharing memory.
Instead, share memory by communicating. The very act of communication guarantees synchronization!

The model

For instance, use a channel to send data to a dedicated server goroutine. If only one goroutine at a time has a pointer to the data, there are no concurrency issues.
This is the model we advocate for programming servers, at least. It’s the old “one thread per client” approach, generalized – and used by us since the 1980s. It works very well.

Related posts:

1. Channels in Go
2. Multiplexing
3. Goroutines

Multiplexing server

type request struct {
a, b int;
replyc chan int;
}
type binOp func(a, b int) int
func run(op binOp, req *request) {
req.replyc <- op(req.a, req.b)
}
func server(op binOp, service chan *request) {
for {
req := <-service; // requests arrive here
go run(op, req); // don't wait for op
}
}

Starting the server

Use the channel function pattern to create a channel to a new server:

func startServer(op binOp) chan *request {
req := make(chan *request);
go server(op, req);
return req
}
var adderChan = startServer(
func(a, b int) int { return a + b }
)

The client

A similar example is worked in more detail in the tutorial, but here’s a variant:

func (r *request) String() string {
return fmt.Sprintf(”%d+%d=%d”,
r.a, r.b, <-r.replyc)
}
req1 := &request{ 7, 8, make(chan int) };
req2 := &request{ 17, 18, make(chan int) };
Requests ready; send them:
adderChan <- req1;
adderChan <- req2;
Can retrieve results in any order; r.replyc demuxes:
fmt.Println(req2, req1);

Teardown

In the mux example, the server runs forever. To tear it down cleanly, signal with a channel. This server has the same functionality but with a quit channel:

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

Starting the server

The rest of the code is mostly the same, with an extra channel:
func startServer(op binOp) (service chan *request,
quit chan bool) {
service = make(chan *request);
quit = make(chan bool);
go server(op, service, quit);
return service, quit;
}
var adderChan, quitChan := startServer(
func(a, b int) int { return a + b }
)

Teardown: the client

The client is unaffected until it’s ready to shut down the server:

req1 := &request{7, 8, make(chan int)};
req2 := &request{17, 18, make(chan int)};
adderChan <- req1;
adderChan <- req2;
fmt.Println(req2, req1);
All done, signal server to exit:
quitChan <- true;

Chaining

package main
import (”flag”; “fmt”)
var ngoroutine = flag.Int(”n”, 100000, “how many”)
func f(left, right chan int) { left <- 1 + <-right }
func main() {
flag.Parse();
leftmost := make(chan int);
var left, right chan int = nil, leftmost;
for i := 0; i < *ngoroutine; i++ {
left, right = right, make(chan int);
go f(left, right);
}
right <- 0; // bang!
x := <-leftmost; // wait for completion
fmt.Println(x); // 100000
}

Example: Leaky bucket

Queue of shared, reusable buffers

var freeList = make(chan *Buffer, 100)
var serverChan = make(chan *Buffer)
func server() {
for {
b := <-serverChan; // wait for work
process(b);
ok := freeList <- b // reuse buffer if room
}
}
func client() {
for {
b, ok := <-freeList; // grab one if available
if !ok { b = new(Buffer) }
load(b);
serverChan <- b // send to server
}
}

No related posts.

Select executes one runnable case at random. If no case is runnable, it blocks until one is. A default clause is always runnable

Random bit generator

Silly but illustrative example.

c := make(chan int);
go func() {
for {
fmt.Println(<-c)
}
}();
for {
select {
case c <- 0: // no stmt, no fall through
case c <- 1:
}
}
Prints 0 1 1 0 0 1 1 1 0 1 …

Related posts:

1. Channels in Go
2. Concurrency
3. Multiplexing

It also has special control structures that build on channels to make concurrent programming easy.

The channel type

In its simplest form the type looks like this:

chan element_type

Given a value of this type, you can send and receive items of element_type. Channels are a reference type, which means if you assign one chan variable to another, both variables access the same channel. It also means you use make to allocate one:

var c = make(chan int)

The communication operator: <-

The arrow points in the direction of data flow.
As a binary operator, <- sends to a channel:

var c chan int;
c <- 1; // send 1 on c (flowing into c)

As a prefix unary operator, <- receives from a channel:
v = <-c; // receive value from c, assign to v
<-c; // receive value, throw it away
i := <-c; // receive value, initialize i

Semantics

By default, communication is synchronous.

This means:
1) A send operation on a channel blocks until a receiver is available for the same channel.
2) A receive operation for a channel blocks until a sender is available for the same channel.
Communication is therefore a form of synchronization: two goroutines exchanging data through a channel synchronize at the moment of communication.

Let’s pump some data

func pump(ch chan int) {
for i := 0; ; i++ { ch <- i }
}
ch1 := make(chan int);
go pump(ch1); // pump hangs; we run
fmt.Println(<-ch1); // prints 0
Now we start a looping receiver.
func suck(ch chan int) {
for { fmt.Println(<-ch) }
}
go suck(ch1); // tons of numbers appear
You can still sneak in and grab a value:
fmt.Println(<-ch); // Prints 314159

Functions returning channels

In the previous example, pump was like a generator spewing out values. But there was a lot of fuss allocating channels etc.
Let’s package it up into a function returning the channel of values.

func pump() chan int {
ch := make(chan int);
go func() {
for i := 0; ; i++ { ch <- i }
}();
return ch
}
stream := pump();
fmt.Println(<-stream); // prints 0
This is a very important idiom.

Channel functions everywhere

I am avoiding repeating famous examples you can find elsewhere. Here are a couple to look up:
1) The prime sieve; in the language specification and also in the tutorial.
2) Doug McIlroy’s power series work.

Range and channels

The range clause on for loops accepts a channel as an operand, in which case the for loops over the values received from the channel.

We rewrote pump; here’s the rewrite for suck, making it launch the goroutine as well:

func suck(ch chan int) {
go func() {
for v := range ch { fmt.Println(v) }
}()
}
suck(pump()); // doesn’t block now

Closing a channel

What if we want to signal that a channel is done?
We close it with a built-in function:
close(ch)
and test that state using closed():

if closed(ch) { fmt.Println(”done”) }

Once a channel is closed and every sent value has been received, every subsequent receive operation will recover a zero value.
In practice, you rarely need close except in certain idiomatic situations.

When a channel closes

There are subtleties about races, so closed() succeeds only after you receive one zero value on the channel. The obvious loop isn’t right. To use closed() correctly you need to say:

for {
v := <-ch;
if closed(ch) { break }
fmt.Println(v)
}

But of course, the range clause does that for you.
for v := range ch {
fmt.Println(v)
}

Iterators

Now we have all the pieces to write an iterator for a container. Here is the code for Vector:

// Iterate over all elements
func (p *Vector) iterate(c chan Element) {
for i, v := range p.a { // p.a is a slice
c <- v
}
close(c); // signal no more values
}
// Channel iterator.
func (p *Vector) Iter() chan Element {
c := make(chan Element);
go p.iterate(c);
return c;
}

Using the iterator

Now that Vector has an iterator, we can use it:

vec := new(vector.Vector);
for i := 0; i < 100; i++ {
vec.Push(i*i)
}
i := 0;
for x := range vec.Iter() {
fmt.Printf("vec[%d] is %d\n", i, x.(int));
i++;
}

Channel directionality

In its simplest form a channel variable is an unbuffered (synchronous) value that can be used to send and receive.

A channel type may be annotated to specify that it may only send or only receive:

var recv_only <-chan int;
var send_only chan<- int;

Channel directionality (II)

All channels are created bidirectional, but we can assign them to directional channel variables.
Useful for instance in functions, for (type) safety:
func sink(ch <-chan int) {
for { <-ch }
}
func source(ch chan<- int) {
for { ch <- 1 }
}
var c = make(chan int); // bidirectional
go source(c);
go sink(c);

Synchronous channels

Synchronous channels are unbuffered. Sends do not complete until a receiver has accepted the value.

c := make(chan int);
go func() {
time.Sleep(60*1e9);
x := <-c;
fmt.Println("received", x);
}();
fmt.Println("sending", 10);
c <- 10;
fmt.Println("sent", 10);
Output: sending 10 (happens immediately)
sent 10 (60s later, these 2 lines appear)
received 10

Asynchronous channels

A buffered, asynchronous channel can be created by giving make an argument, the number of elements in the buffer.
c := make(chan int, 50);
go func() {
time.Sleep(60*1e9);
x := <-c;
fmt.Println("received", x);
}();
fmt.Println("sending", 10);
c <- 10;
fmt.Println("sent", 10);
Output: sending 10 (happens immediately)
sent 10 (now)
received 10 (60s later)

Buffer is not part of the type

Note that the buffer's size, or even its existence, is not part of the channel's type, only of the value. This code is therefore legal, although dangerous:
buf = make(chan int, 1);
unbuf = make(chan int);
buf = unbuf;
unbuf = buf;

Buffering is a property of the value, not of the type.

Testing for communicability

Can a receive proceed without blocking? Need to find out and execute, or not, atomically.
"Comma ok" to the rescue:
v, ok = <-c; // ok=true if v received value

Can a send proceed without blocking? Need to find out and execute, or not, atomically. Use send as a boolean expression:
ok := c <- v;
or
if c <- v { fmt.Println("sent value") }

Select

Select is a control structure in Go analogous to a communications switch statement. Each case must be a communication, either send or receive.

var c1, c2 chan int;
select {
case v := <-c1:
fmt.Printf("received %d from c1\n", v)
case v := <-c2:
fmt.Printf("received %d from c2\n", v)
}

Select executes one runnable case at random. If no case is runnable, it blocks until one is. A default clause is always runnable

Related posts:

1. Concurrency
2. Multiplexing
3. Select

Definition

A goroutine is a Go function or method executing concurrently in the same address space as other goroutines.
A running program consists of one or more goroutines. It’s not the same as a thread, coroutine, process, etc. It’s a goroutine.

Starting a goroutine

Invoke a function or method and say go:

func IsReady(what string, minutes int64) {
time.Sleep(minutes * 60*1e9);
fmt.Println(what, “is ready”)
}
go IsReady(”tea”, 6);
go IsReady(”coffee”, 2);
fmt.Println(”I’m waiting….”);
Prints:
I’m waiting…. (right away)
coffee is ready (2 min later)
tea is ready (6 min later)

Some simple facts

Goroutines are cheap.
Goroutines exit by returning from their toplevel function, or just falling off the end. Or
they can call runtime.Goexit(), although that’s rarely necessary.

Goroutines can run concurrently on different processors, sharing memory.
You don’t have to worry about stack size.

Stacks

In gccgo, at least for now, goroutines are pthreads.

Stacks are big. We will fix this soon (our solution requires changes to gcc itself).
In 6g, however, stacks are small (a few kB) and grow as needed. Thus in 6g, goroutines use little memory, you can have lots of them, and they can dynamically have huge stacks.

Scheduling

Goroutines are multiplexed as needed onto system threads. When a goroutine executes a blocking system call, no other goroutine is blocked.

We will do the same for CPU-bound goroutines at some point, but for now, if you want user-level parallelism you must set $GOMAXPROCS. or call runtime.GOMAXPROCS(n).

GOMAXPROCS tells the runtime scheduler how many non-syscall-blocked goroutines to run at once.

Related posts:

1. Concurrency

The defer statement executes a function (or method) when the enclosing function returns. The arguments are evaluated at the point of the defer; the function call happens upon return.

func data(name string) string {

f := os.Open(name, os.O_RDONLY, 0);

defer f.Close();

contents := io.ReadAll(f);

return contents;

}

Useful for closing fds, unlocking mutexes, etc.

Tracing with defer

func trace(s string) { Print(”entering:”, s); }

func untrace(s string) { Print(”leaving:”, s); }

func a() {

trace(”a”);

defer untrace(”a”);

Print(”in a”)

}

func b() {

trace(”b”);

defer untrace(”b”);

Print(”in b”);

a()

}

func main() { b() }

Args evaluate now, defer later

func trace(s string) string {

Print(”entering:”, s);

return s

}

func un(s string) {

Print(”leaving:”, s)

}

func a() {

defer un(trace(”a”));

Print(”in a”)

}

func b() {

defer un(trace(”b”));

Print(”in b”);

a()

}

func main() { b() }

No related posts.

Functions

Functions are introduced by the func keyword.

Return type, if any, comes after parameters. The return does as you expect.

func square(f float) float { return f*f }

A function can return multiple values. If so, the return types are a parenthesized list.

func MySqrt(f float) (float, bool) {

if f >= 0 { return math.Sqrt(f), true }

return 0, false

}

Functions with result variables

The result “parameters” are actual variables you can use if you name them.

func MySqrt(f float) (v float, ok bool) {

if f >= 0 { v,ok = math.Sqrt(f),true }

else { v,ok = 0,false }

return v,ok

}

The result variables are initialized to “zero”

(0,0.0, false etc. according to type; more in a sec).

func MySqrt(f float) (v float, ok bool) {

if f >= 0 { v,ok = math.Sqrt(f),true }

return v,ok

}

The empty return

Finally, a return with no expressions returns the existing value of the result variables. Two more versions of MySqrt:

func MySqrt(f float) (v float, ok bool) {

if f >= 0 { v,ok = math.Sqrt(f),true }

return // must be explicit

}

func MySqrt(f float) (v float, ok bool) {

if f < 0 { return } // error case

return math.Sqrt(f),true

}

Function literals

As in C, functions can’t be declared inside functions -but function literals can be assigned to variables.

func f() {

for i := 0; i < 10; i++ {

g := func(i int) { fmt.Printf(”%d”,i) };

g(i);

}

}

Function literals are closures

Function literals are indeed closures.

func adder() (func(int) int) {

var x int;

return func(delta int) int {

x += delta;

return x

}

}

var f = adder();

fmt.Print(f(1));

fmt.Print(f(20));

fmt.Print(f(300));

Prints 1 21 321 – accumulating in f’s x

No related posts.

Declarations
Declarations are introduced by a keyword
var
const
type
func

and look reversed compared to C:

var i int
const PI = 22./7.
type Point struct { x, y int }
func sum(a, b int) int { return a + b }

Why are they reversed? Earlier example:
var p, q *int
Also functions read better and are consistent with other declarations.

Var

Variable declarations are introduced by var.
They may have a type or an initialization expression; one or both must be present. Initializers must match variables (and types!).

var i int
var j = 365.245
var k int = 0
var l, m uint64 = 1, 2
var billion int64 = 1e9 // float constant!
var inter, floater, stringer = 1, 2.0, “hi”

Distributing var

Annoying to type var all the time. Group with parens! Need semicolons as separators.

var (
i int;
j = 356.245;
k int = 0;
l, m uint64 = 1, 2;
billion int64 = 1e9;
inter, floater, stringer = 1, 2.0, “hi”
)

Applies to const, type, var

The := “short declaration”

Within functions (only), declarations of the form

var v = value
can be shortened to
v := value

(Another reason for the name/type reversal.)
The type is that of the value (for ideal numbers, get
int or float, accordingly.)

a, b, c, d := 1, 2.0, “three”, FOUR

These are used a lot and are available in places such as for loop initializers.

Const

Constant declarations are introduced by const.
They must have a “constant expression”, evaluated at compile time, as initializer and may have an optional type specifier.

const Pi = 22./7.
const AccuratePi float64 = 355./113
const beef, two, parsnip = “meat”, 2, “veg”
const (
Monday, Tuesday, Wednesday = 1, 2, 3;
Thursday, Friday, Saturday = 4, 5, 6;
)

Iota

Constant declarations can use the counter iota, which starts at 0 in each const block and increments at each semicolon.

const (
Monday = iota; // 0
Tuesday = iota; // 1
)

Shorthand: Previous type and expressions repeat.
const (
loc0, bit0 uint32 = iota, 1&lt;
loc1, bit1; // 1, 2
loc2, bit2; // 2, 4
)

Type

Type declarations are introduced by type.
We’ll learn more about types later but here are some examples:

type Point struct {
x, y, z float;
name string
}

type Operator func(a, b int) int
type ArrayOfIntPointers []*int
We’ll come back to functions a little later.

New

The new() operator allocates memory. Syntax is like a function call, with type as argument, similar to C++. Returns a pointer to the allocated object.

var p *Point = new(Point)
v := new(int) // v has type *int

Later we’ll see how to build arrays and such.
There is no delete or free; Go has garbage collection.

Assignment
Assignment is easy and familiar:
a = b
But multiple assignment works too:
x, y, z = f1(), f2(), f3()
a, b = b, a

No related posts.

Go Programming Language Promo

The Go Programming Language

No related posts.

Expressions

Mostly C-like operators.

Binary operators:

• Operators that are also unary: & ! * + – ^ <-
• Unary ^ is complement.

Go vs. C expressions

Surprises for the C programmer:

fewer precedence levels (should be easy)

^ instead of ~ (it’s binary “exclusive or” made unary)

++ and — are not expression operators

(x++ is a statement, not an expression;

*p++ is (*p)++ not *(p++))

&^ is new; handy in constant expressions

<< >> etc. require an unsigned shift count

Non-surprises:

assignment ops work as expected: += <<= &^= etc.

expressions generally look the same (indexing,

function call, etc.)

Examples

+x

23 + 3*x[i]

x <= f()

^a >> b

f() || g()

x == y + 1 && <-chan_ptr > 0

x &^ 7 // x with the low 3 bits cleared

fmt.Printf(”%5.2g\n”, 2*math.Sin(PI/8))

“hello” “, ” “there” // lexical cat

“hello, ” + str // dynamic cat

Numeric conversions

Converting a numeric value from one type to another is a conversion, with syntax like a function call:

uint8(int_var)       // truncate to size

int(float_var)        // truncate fraction

float64(int_var)    // convert to float

Also some conversions to string:

string(0×1234)     // == “\u1234″

string(array_of_bytes)   // bytes -> bytes

string(array_of_ints)      // ints -> Unicode/UTF-8

Constants

Numeric constants are “ideal numbers”: no size or sign, hence no l or u or ul endings.

Example:

077 // octal

0xFEEDBEEEEEEEEEEEEEEEEEEEEF // hexadecimal

1 << 100

There are integer and floating-point ideal numbers; syntax of literal determines type:

Example:

1.234e5

1e2 // floating-point

100 // integer

Constant Expressions

Floating point and integer constants can be combined at will, with the type of the resulting expression determined by the type of the constants.

The operations themselves also depend on the type.

2*3.14        // floating point: 6.28

3./2    // floating point: 1.5

3/2     // integer: 1

// high precision:

const Ln2

= 0.693147180559945309417232121458\

176568075500134360255254120680009

const Log2E

= 1/Ln2       // accurate reciprocal

Representation is “big enough” (1024 bits now).

Consequences of ideal numbers

The language permits the use of constants without explicit conversion if the value can be represented

var million int = 1e6      / float constant

math.Sin(1)

Constants must be representable in their type.

Example:

^0 is -1 which is not in range 0-255.

uint8(^0)     / bad: -1 can’t be represented

^uint8(0)     // OK

uint8(350)   // bad: 350 can’t be represented

uint8(35.0) // OK: 35

uint8(3.5)    // bad: 3.5 can’t be represented

No related posts.