Channel synchronization in Go - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Go program using channels?

Consider this Go program that uses a channel to synchronize goroutines. What will it print?

Go

package main

import (
	"fmt"
)

func main() {
	ch := make(chan string)
	go func() {
		ch <- "hello"
	}()
	msg := <-ch
	fmt.Println(msg)
}

A hello

B Compilation error

C Deadlock detected at runtime

D Empty line printed

💡 Hint

Think about how the channel is used to pass data between goroutines.

The goroutine sends the string "hello" into the channel. The main goroutine receives it and prints it. So the output is "hello".

❓ Predict Output

intermediate

What happens if you read from a closed channel?

What will this Go program print?

Go

package main

import (
	"fmt"
)

func main() {
	ch := make(chan int)
	go func() {
		ch <- 42
		close(ch)
	}()
	val, ok := <-ch
	fmt.Println(val, ok)
	val, ok = <-ch
	fmt.Println(val, ok)
}

A

42 true
42 true

B

42 true
0 false

C Compilation error

D Deadlock at runtime

💡 Hint

Remember what happens when you read from a closed channel in Go.

Reading from a closed channel returns the zero value and false for the second value. The first read gets 42 and true, the second read gets 0 and false.

🔧 Debug

advanced

Why does this Go program deadlock?

Examine this Go program. It deadlocks at runtime. Why?

Go

package main

func main() {
	ch := make(chan int)
	ch <- 1
	<-ch
}

A Because the channel is nil

B Because the channel is closed before sending

C Because the channel is unbuffered and no goroutine is receiving when sending

D Because the channel is buffered but full

💡 Hint

Think about how unbuffered channels block on send and receive.

The send operation blocks because no goroutine is ready to receive from the unbuffered channel. This causes a deadlock.

📝 Syntax

advanced

Which option correctly creates a buffered channel of size 3?

Choose the correct Go code to create a buffered channel of integers with capacity 3.

A ch := make(chan int[3])

B ch := make(chan int)

C ch := make(chan int, "3")

D ch := make(chan int, 3)

💡 Hint

Recall the syntax of make for buffered channels.

make(chan int, 3) creates a buffered channel with capacity 3. The second argument is the buffer size as an integer.

🚀 Application

expert

How many items are in the channel after this code runs?

Given this Go code, how many items remain in the channel after execution?

Go

package main

import (
	"fmt"
)

func main() {
	ch := make(chan int, 5)
	for i := 0; i < 3; i++ {
		ch <- i
	}
	<-ch
	ch <- 10
	fmt.Println(len(ch))
}

A 4

B 3

C 2

D 5

💡 Hint

Count how many sends and receives happen on the buffered channel.

Initially 3 items sent, then 1 item received (removes one), then 1 item sent again. So total items in channel: 3 - 1 + 1 = 3. But len(ch) returns 3, so answer is 3.

Practice

1. What happens when a goroutine tries to send data on an unbuffered channel if no other goroutine is ready to receive?

easy

A. The sending goroutine waits until another goroutine receives the data.

B. The data is lost and the program continues immediately.

C. The program crashes with a runtime error.

D. The data is buffered automatically for later use.

Solution

1. Step 1: Understand unbuffered channel behavior

   Unbuffered channels require both sender and receiver to be ready at the same time for communication.

2. Step 2: Analyze sending on unbuffered channel

   If no goroutine is ready to receive, the sending goroutine blocks and waits until a receiver is ready.

3. Final Answer:

   The sending goroutine waits until another goroutine receives the data. -> Option A

4. Quick Check:

   Unbuffered channel send blocks until receive [OK]

Hint: Unbuffered sends block until a receiver is ready [OK]

Common Mistakes:

• Thinking data is buffered automatically
• Assuming send never blocks
• Believing program crashes on send

2. Which of the following is the correct syntax to create a buffered channel of integers with capacity 3 in Go?

easy

A. ch := chan int{3}

B. ch := make(chan int)

C. ch := make(chan int, 3)

D. ch := new(chan int, 3)

Solution

1. Step 1: Recall channel creation syntax

   Channels are created using make with type and optional buffer size: make(chan Type, capacity).

2. Step 2: Identify correct buffered channel syntax

   To create a buffered channel of int with capacity 3, use make(chan int, 3).

3. Final Answer:

   ch := make(chan int, 3) -> Option C

4. Quick Check:

   Buffered channel syntax = make(chan Type, capacity) [OK]

Hint: Use make(chan Type, capacity) for buffered channels [OK]

Common Mistakes:

• Omitting buffer size for buffered channel
• Using new() instead of make()
• Incorrect channel literal syntax

3. What will be the output of the following Go program?

package main
import "fmt"
func main() {
  ch := make(chan string)
  go func() {
    ch <- "hello"
  }()
  msg := <-ch
  fmt.Println(msg)
}

medium

A. Compilation error

B. No output

C. Deadlock runtime error

D. hello

Solution

1. Step 1: Analyze channel and goroutine

   A goroutine sends "hello" on an unbuffered channel ch, while main receives from ch.

2. Step 2: Understand synchronization

   The send and receive synchronize, so main receives "hello" and prints it.

3. Final Answer:

   hello -> Option D

4. Quick Check:

   Send and receive synchronize, printing message [OK]

Hint: Unbuffered channel send/receive synchronize to pass data [OK]

Common Mistakes:

• Expecting deadlock because of goroutine
• Thinking channel is buffered by default
• Assuming no output due to concurrency

4. Identify the error in this Go code snippet involving channel synchronization:

package main
func main() {
  ch := make(chan int)
  ch <- 5
  val := <-ch
  println(val)
}

medium

A. No error, code runs fine.

B. Sending on channel blocks forever causing deadlock.

C. Channel is not initialized properly.

D. Receiving from channel blocks forever causing deadlock.

Solution

1. Step 1: Check channel creation and usage

   Channel ch is unbuffered and created correctly with make(chan int).

2. Step 2: Analyze send operation

   Sending on unbuffered channel blocks until another goroutine receives. Here, send happens before receive, no other goroutine receives, so it blocks forever.

3. Final Answer:

   Sending on channel blocks forever causing deadlock. -> Option B

4. Quick Check:

   Send blocks without concurrent receiver [OK]

Hint: Send on unbuffered channel blocks if no receiver ready [OK]

Common Mistakes:

• Thinking receive blocks first
• Assuming channel is nil
• Believing code runs without deadlock

5. You want to run three tasks concurrently and wait for all to finish before exiting. Which Go code snippet correctly uses channels to synchronize all tasks?

hard

A. Use a buffered channel with capacity 3; each goroutine sends a signal when done; main receives 3 signals.

B. Use an unbuffered channel; main sends signals to goroutines to start; no synchronization on finish.

C. Use a buffered channel with capacity 1; goroutines send signals; main receives once.

D. Use no channels; just start goroutines and exit main immediately.

Solution

1. Step 1: Understand synchronization goal

   Main must wait for all 3 goroutines to finish before exiting.

2. Step 2: Analyze channel usage options

   Buffered channel with capacity 3 allows all goroutines to send done signals without blocking; main receives 3 signals to know all finished.

3. Final Answer:

   Use a buffered channel with capacity 3; each goroutine sends a signal when done; main receives 3 signals. -> Option A

4. Quick Check:

   Buffered channel capacity = number of goroutines to sync [OK]

Hint: Use buffered channel sized to goroutines for sync signals [OK]

Common Mistakes:

• Using unbuffered channel causing deadlock
• Receiving fewer signals than goroutines
• Not waiting for goroutines at all