Common concurrency patterns in Go - Step-by-Step Execution

Concept Flow - Common concurrency patterns

Start Goroutine

↓

Perform Task Concurrently

↓

Communicate via Channel

↓

Synchronize with WaitGroup

↓

Collect Results

↓

Main Goroutine Continues

This flow shows how Go runs tasks concurrently using goroutines, communicates results through channels, and synchronizes completion with WaitGroups.

Execution Sample

Go

package main
import (
 "fmt"
 "sync"
)
func main() {
 var wg sync.WaitGroup
 ch := make(chan string)
 wg.Add(1)
 go func() {
  defer wg.Done()
  ch <- "Hello from goroutine"
 }()
 go func() {
  wg.Wait()
  close(ch)
 }()
 for msg := range ch {
  fmt.Println(msg)
 }
}

This Go program starts a goroutine that sends a message through a channel, waits for it to finish, then closes the channel so the main goroutine can print the message.

Execution Table

Step	Action	Goroutine State	Channel State	WaitGroup Counter	Output
1	Main starts, creates WaitGroup and channel	Main running	Empty	0
2	Main adds 1 to WaitGroup	Main running	Empty	1
3	Start goroutine to send message	Goroutine started	Empty	1
4	Goroutine sends "Hello from goroutine" to channel	Goroutine blocked on send	Empty (send blocked)	1
5	Main starts goroutine to wait and close channel	Wait goroutine started	Empty (send blocked)	1
6	Main reads from channel	Main receives from channel	Empty after read	1	Hello from goroutine
7	Goroutine finishes, calls Done()	Goroutine finished	Empty	0
8	Wait goroutine detects WaitGroup counter 0, closes channel	Wait goroutine finished	Closed	0
9	Main loop ends as channel closed	Main finished	Closed	0

💡 Channel closed after WaitGroup counter reached zero, main loop ends.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 7	Final
WaitGroup counter	0	1	1	1	0	0
Channel state	empty	empty	empty	empty	empty	closed
Output	""	""	""	"Hello from goroutine"	"Hello from goroutine"	"Hello from goroutine"

Key Moments - 3 Insights

Why does the goroutine block when sending to the channel at step 4?

Because the channel is unbuffered and no goroutine is ready to receive yet, the send operation waits until the main goroutine reads from the channel (step 6).

Why do we need a separate goroutine to wait and close the channel?

Closing the channel after all sends are done signals the main goroutine to stop reading. The wait goroutine waits for WaitGroup counter to reach zero before closing, ensuring no sends happen after close.

What happens if we forget to call wg.Done() in the sending goroutine?

The WaitGroup counter never decreases, so the wait goroutine never closes the channel, causing the main goroutine to block forever waiting for more messages.

Visual Quiz - 3 Questions

Look at the execution table, what is the WaitGroup counter after step 7?

A 0

B 1

C 2

D Undefined

💡 Hint

Check the 'WaitGroup Counter' column at step 7 in the execution table.

At which step does the main goroutine receive the message from the channel?

A Step 4

B Step 6

C Step 8

D Step 9

💡 Hint

Look at the 'Output' column to see when the message appears.

If the channel was buffered with capacity 1, how would step 4 change?

A Goroutine would block waiting for receiver

B Channel would close immediately

C Goroutine would send without blocking

D WaitGroup counter would increase

💡 Hint

Buffered channels allow one send without waiting for a receiver.

Concept Snapshot

Go concurrency uses goroutines to run tasks at the same time.
Channels let goroutines send and receive messages safely.
WaitGroups help wait for many goroutines to finish.
Unbuffered channels block senders until receivers are ready.
Closing a channel signals no more messages will come.
Use these patterns to coordinate concurrent work safely.

Full Transcript

This visual execution trace shows how Go uses common concurrency patterns: starting goroutines, communicating via channels, and synchronizing with WaitGroups. The main goroutine creates a WaitGroup and a channel, then starts a goroutine that sends a message through the channel. Because the channel is unbuffered, the sending goroutine blocks until the main goroutine reads the message. Another goroutine waits for the WaitGroup counter to reach zero and then closes the channel, signaling the main goroutine to stop reading. The variable tracker shows how the WaitGroup counter and channel state change step by step. Key moments clarify why blocking happens on unbuffered channels, why closing channels is done after all sends, and the importance of calling Done on the WaitGroup. The quiz tests understanding of WaitGroup counters, message receipt timing, and buffered channel behavior. This pattern is essential for safe and effective concurrent programming in Go.