Introduction to Concurrency

This interactive guide explores Go's powerful and simple approach to concurrent programming. Go was designed with concurrency as a first-class citizen, making it easier to build responsive, high-performance applications that can handle many tasks at once.

Goroutines

Goroutines are the fundamental building blocks of concurrency in Go. A goroutine is a lightweight thread of execution managed by the Go runtime.

Launching a Goroutine

Starting a goroutine is incredibly simple. You just use the `go` keyword before a function call. This tells Go to run the function concurrently, without blocking the current flow.

go myFunction() // Run myFunction in a new goroutine

Goroutines vs. OS Threads

Goroutines are not the same as the operating system threads you might be familiar with from other languages. They are much more efficient, allowing you to run thousands or even millions of them at once.

The Main Goroutine

Every Go program starts with a single goroutine: the `main` goroutine. If the `main` goroutine finishes, the program exits immediately, even if other goroutines are still running. You must explicitly wait for other goroutines to complete if their work is important.

Channels

Channels are the pipes that connect concurrent goroutines. You can send values into channels from one goroutine and receive those values into another goroutine, providing a safe and easy way to communicate.

Creating and Using Channels

// Create a channel for integers
ch := make(chan int)

// Send a value to the channel
ch <- 42

// Receive a value from the channel
value := <-ch

Unbuffered Channels (Synchronous)

By default, channels are unbuffered. This means they will only accept a send if there is a corresponding receive ready to take the value. Both send and receive operations block until the other side is ready. This makes them great for synchronization.

Buffered Channels (Asynchronous)

You can also create buffered channels with a fixed capacity. Sends to a buffered channel only block if the buffer is full, and receives only block if the buffer is empty. This decouples the sender and receiver.

The `select` Statement

The `select` statement lets a goroutine wait on multiple channel operations. It's like a `switch` statement, but for channels. A `select` blocks until one of its cases can run, then it executes that case. If multiple are ready, it chooses one at random.

Basic `select`

select {
case msg1 := <-ch1:
    fmt.Println("received", msg1)
case msg2 := <-ch2:
    fmt.Println("received", msg2)
}

Timeouts with `select`

A very common use of `select` is to implement timeouts. By combining a case for your operation with a case for `time.After`, you can prevent a goroutine from waiting forever.

select {
case res := <-operationChannel:
    fmt.Println(res)
case <-time.After(1 * time.Second):
    fmt.Println("operation timed out!")
}

Non-Blocking Operations with `default`

Adding a `default` case to a `select` makes it non-blocking. If no other case is ready, the `default` case will run immediately.

select {
case msg := <-messages:
    fmt.Println("received message", msg)
default:
    fmt.Println("no message received")
}

Synchronization Primitives

While channels are the preferred way to communicate, sometimes you need more traditional synchronization tools. The `sync` package provides these for situations involving shared memory.

Context Package

The `context` package is essential for managing the lifecycle of requests and goroutines. It allows you to pass deadlines, cancellation signals, and other request-scoped values across API boundaries and between goroutines.

Key Concepts

• Cancellation: A parent operation can cancel all the goroutines it has started.
• Timeouts/Deadlines: You can set a time limit for an operation. If it takes too long, it's automatically canceled.
• Request-scoped Values: Carry data like user IDs or trace IDs through a call stack without passing them as arguments to every function.

How it Works

You create a `context` and pass it to functions. These functions can then listen for a cancellation signal on the context's `Done()` channel using a `select` statement. When the context is canceled (either manually or by a timeout), the `Done()` channel is closed, and the goroutines can clean up and exit gracefully.

func worker(ctx context.Context) {
    select {
    case <-time.After(2 * time.Second):
        fmt.Println("work done")
    case <-ctx.Done(): // Check if context was canceled
        fmt.Println("work canceled:", ctx.Err())
    }
}

func main() {
    // Create a context that times out after 1 second
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel() // Important to call cancel to release resources

    worker(ctx) // This will print "work canceled: context deadline exceeded"
}

Passing a `context` as the first argument to functions is a standard convention in modern Go code, especially for network services and long-running tasks.

Common Concurrency Patterns

Go's primitives enable several powerful patterns for structuring concurrent work.

Common Concurrency Issues

While Go makes concurrency easier, it doesn't eliminate common pitfalls. Understanding them is key to writing robust code.

Go Memory Model

The Go Memory Model specifies the conditions under which a read of a variable in one goroutine is guaranteed to observe the value written by another goroutine. This is defined by the "happens-before" relationship.

Synchronization Establishes "Happens-Before"

You must use synchronization primitives to establish a happens-before relationship between goroutines:

• A send on a channel happens-before the corresponding receive completes.
• The closing of a channel happens-before a receive that returns a zero value because the channel is closed.
• An unlock of a `sync.Mutex` happens-before a subsequent lock on the same mutex.

The core message is: if you are accessing shared data from multiple goroutines, you must use a synchronization mechanism.