Blocking behavior in Go - Step-by-Step Execution

Concept Flow - Blocking behavior

Start goroutine or channel operation

↓

Check if resource/channel ready

↓

Block and wait

↓

Continue execution

This flow shows how Go waits (blocks) when a goroutine tries to read/write on a channel or waits for a resource until it becomes ready.

Execution Sample

Go

package main
import "fmt"
func main() {
  ch := make(chan int)
  ch <- 1
  fmt.Println("Sent 1")
}

This code tries to send a value on an unbuffered channel without a receiver, causing the program to block.

Execution Table

Step	Action	Channel State	Blocking?	Output
1	Create unbuffered channel ch	empty	No
2	Attempt to send 1 on ch	empty	Yes, blocks waiting for receiver
3	No receiver available, program waits	empty	Yes
4	Program stuck, no output	empty	Yes

💡 Program blocks indefinitely because no goroutine is receiving from the channel

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
ch	nil	empty channel	empty channel (blocked send)	empty channel (blocked send)

Key Moments - 2 Insights

Why does the program stop at step 2 and not print anything?

Because sending on an unbuffered channel blocks until another goroutine receives from it, and here no receiver exists, so the program waits forever (see execution_table step 2 and 3).

What does 'blocking' mean in this context?

It means the program pauses at that line, waiting for a condition (like a receiver on the channel) before continuing, as shown in the execution_table where the send operation waits.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the program start blocking?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Blocking?' column in execution_table for when blocking first occurs.

According to variable_tracker, what is the state of channel 'ch' after step 2?

A nil

B closed channel

C empty channel (blocked send)

D buffered channel with 1 item

💡 Hint

Look at the 'After Step 2' column for variable 'ch' in variable_tracker.

If a receiver goroutine was added before sending, how would the execution_table change?

A No blocking; send and receive happen immediately

B Program would crash

C Blocking would still occur at step 2

D Channel would close automatically

💡 Hint

Think about how unbuffered channels synchronize send and receive without blocking if both exist.

Concept Snapshot

Blocking behavior in Go:
- Sending or receiving on unbuffered channels blocks until the other side is ready.
- Blocking pauses the goroutine at that line.
- Without a receiver, sending blocks forever.
- Adding a receiver allows send to proceed immediately.
- Blocking ensures synchronization between goroutines.

Full Transcript

This example shows blocking behavior in Go when sending on an unbuffered channel without a receiver. The program creates a channel, then tries to send a value. Because no goroutine receives from the channel, the send operation blocks and the program waits indefinitely. Variables track the channel state as empty but blocked. Blocking means the program pauses until the condition to continue is met. Adding a receiver would prevent blocking by allowing the send to complete immediately.