Concurrency Boundaries

Use context for cancellation and timeouts, protect shared state with mutexes, and catch races with go test -race.

8 min readProgramming Foundations (Go)Code

context.Context and Cancellation

context.Context carries cancellation signals, deadlines, and request-scoped values across API boundaries. Pass it as the first parameter to any function that does I/O or long-running work.

Gocancelling-a-goroutine-with-context.go

34 linesLn 1, Col 1Go

`context.WithCancel` returns a child context and a cancel function. Calling `cancel()` closes `ctx.Done()`, which all workers listening on that channel detect. Always call cancel — even if the work finishes before cancellation.

Always call the cancel function

The cancel function returned by context.WithCancel, WithTimeout, and WithDeadline must always be called — even if the work completes normally. Not calling it leaks the context and associated resources. The standard idiom is defer cancel() immediately after the context is created.

Timeouts with context

context.WithTimeout automatically cancels after a duration. context.WithDeadline cancels at a specific time. Both are the standard way to add timeouts to HTTP requests, database calls, and any operation that can hang.

Gohttp-request-with-a-timeout.go

35 linesLn 1, Col 1Go

`http.NewRequestWithContext` attaches the context to the request. If the context times out before the response arrives, the HTTP client returns an error containing `context.DeadlineExceeded`.

sync.Mutex for Shared State

When goroutines share mutable state, use a sync.Mutex to ensure only one goroutine accesses it at a time. The pattern is: lock before reading or writing, unlock immediately after.

Gosafe-counter-with-mutex.go

40 linesLn 1, Col 1Go

`defer c.mu.Unlock()` ensures the mutex is always released, even if the function panics or has multiple return paths. `sync.RWMutex` allows multiple concurrent readers and one exclusive writer — useful when reads vastly outnumber writes.

The Race Detector

Go has a built-in race detector that instruments your program at runtime to detect concurrent reads and writes to the same memory. Run it with go test -race or go run -race.

Goa-race-condition-the-detector-finds.go

23 linesLn 1, Col 1Go

Running this with `go run -race main.go` reports a data race on `counter`. The fix is either a `sync.Mutex` (as in the previous example) or `sync/atomic.AddInt64` for simple numeric operations.

Running the race detector


# In tests (recommended — run this in CI)
go test -race ./...

# On a specific program
go run -race main.go

# Build with race detection (for production use on specific services)
go build -race -o server-race .

The race detector has a small runtime overhead (5-20x slower, ~5-10x more memory). Run it in your CI test suite on every commit. Do not ship race-detected binaries to production unless you are specifically hunting a race in a controlled environment.

Pass context.Context as the first parameter to every function that does I/O or long-running work.
Always defer cancel() immediately after creating a cancellable context.
Use sync.Mutex (or sync.RWMutex) to protect shared mutable state.
Run go test -race ./... in CI on every commit.
Prefer channels for communicating ownership; prefer mutexes for protecting a shared cache or counter.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.

Stage 1 · Code

Packages, Modules & Concurrency Intro