Goroutines and WaitGroup

Concurrency and parallelism

Concurrency means dealing with many tasks whose lifetimes overlap: while one waits for the network, another runs. Parallelism means literally running at the same instant on different CPU cores. Go makes concurrency easy; the Go runtime then spreads goroutines across cores, which gives parallelism when the machine has several cores.

Starting a goroutine

func sendSMS(to string) {
	time.Sleep(100 * time.Millisecond) // pretend network call
	fmt.Println("sent to", to)
}

func main() {
	go sendSMS("98XXXXXX01") // runs concurrently
	go sendSMS("98XXXXXX02")
	fmt.Println("main is done")
	// main returns here: the program exits, probably before any SMS is "sent"
}

Why goroutines are cheap

• A goroutine starts with a small stack of a few kilobytes that grows only when needed. An operating-system thread usually reserves much more.
• The Go runtime has its own scheduler. It runs many goroutines on a small number of OS threads, switching between them when one blocks on I/O, a channel or a lock.
• GOMAXPROCS sets how many threads run Go code at the same time. It defaults to the number of CPU cores (and, since Go 1.25 on Linux, respects container CPU limits).
• So a web server can give every request its own goroutine. That is exactly what net/http does.

Waiting with sync.WaitGroup

func main() {
	phones := []string{"98XXXXXX01", "98XXXXXX02", "98XXXXXX03"}
	var wg sync.WaitGroup
	for _, p := range phones {
		wg.Add(1)              // one more goroutine to wait for
		go func() {
			defer wg.Done()    // this one is finished
			sendSMS(p)
		}()
	}
	wg.Wait()                  // block until the counter is zero
	fmt.Println("all sent")
}

• Call wg.Add(1) BEFORE the go statement, not inside the goroutine, or Wait might run before Add.
• Call wg.Done() with defer, so it runs even if the function returns early.
• Pass a WaitGroup by pointer if you hand it to another function; copying it breaks it (go vet warns).
• Go 1.25 added wg.Go(func() { ... }), which does Add, go and Done for you. Older code uses the three calls above.

Order is not guaranteed

Goroutines run in whatever order the scheduler picks. Never assume goroutine 1 finishes before goroutine 2. If order matters, collect results with their index and sort, or send them through channels (next topic).

Returning results

prices := []int{100, 250, 499}
results := make([]int, len(prices))
var wg sync.WaitGroup
for i, p := range prices {
	wg.Add(1)
	go func() {
		defer wg.Done()
		results[i] = p + p*18/100 // each goroutine writes its OWN index: safe
	}()
}
wg.Wait()
fmt.Println(results) // [118 295 588]