Week 6: Goroutines & Channels: Concurrency Fundamentals

1. Launching Goroutines

The go keyword before a function call runs it concurrently, as a goroutine, without blocking the caller. A goroutine starts with a tiny (as little as 2KB) growable stack, managed by the Go runtime rather than the OS — which is why launching thousands of them is routine in Go, where launching thousands of OS threads would exhaust memory and scheduler overhead fast.

func sayHello() {
    fmt.Println("hello from a goroutine")
}

func main() {
    go sayHello()             // runs concurrently, doesn't block
    time.Sleep(100 * time.Millisecond) // crude — just to let it finish before main exits
    fmt.Println("main done")
}

time.Sleep here is a placeholder, not a real synchronization mechanism — if main returns before the goroutine runs, the whole program exits and the goroutine's output never appears. Channels (next) and sync.WaitGroup (Week 7) are the real tools for this.

2. Channels for Safe Communication

A channel is a typed pipe goroutines use to send and receive values — and to synchronize, since a send and a receive on an unbuffered channel both block until the other side is ready.

func sayHello(done chan bool) {
    fmt.Println("hello from a goroutine")
    done <- true // send: signals completion
}

func main() {
    done := make(chan bool)
    go sayHello(done)
    <-done // receive: blocks until sayHello sends
    fmt.Println("main done")
}

This is Go's core concurrency philosophy in miniature: instead of two goroutines both reaching into a shared variable (and needing locks to do it safely), one goroutine sends its result to another through a channel — ownership of the data transfers cleanly, with no shared mutable state to protect.

3. Buffered vs. Unbuffered Channels

unbuffered := make(chan int)     // capacity 0
buffered := make(chan int, 3)     // capacity 3

go func() {
    unbuffered <- 1 // blocks here until something receives
}()
fmt.Println(<-unbuffered) // 1 — unblocks the sender above

buffered <- 1 // does NOT block — there's room
buffered <- 2 // still doesn't block
buffered <- 3 // still fits
// buffered <- 4 would block here — the buffer is full

An unbuffered channel forces a handoff — the sender waits for a receiver and vice versa, which is a strong synchronization guarantee ("this happened before that"). A buffered channel decouples them up to its capacity, useful for smoothing out bursts of work, but it gives up that strict handoff guarantee in exchange.

4. Avoiding Deadlocks

The most common beginner deadlock: sending on an unbuffered channel with nobody ever going to receive.

func main() {
    ch := make(chan int)
    ch <- 1 // blocks forever — nothing will ever receive on the main goroutine
    fmt.Println(<-ch)
}
// fatal error: all goroutines are asleep - deadlock!

The fix is almost always structural: the send needs to happen from a different goroutine than the receive, so one can proceed while the other is blocked waiting.

func main() {
    ch := make(chan int)
    go func() {
        ch <- 1 // runs on its own goroutine — free to block here
    }()
    fmt.Println(<-ch) // main receives — unblocks the goroutine above
}

Go's runtime is specifically able to detect the case where every goroutine is blocked with no possible way forward, and crashes immediately with a clear "deadlock!" message rather than hanging silently forever — genuinely useful during development, since it turns a subtle bug into a loud, immediate one.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.