Hone logo
Hone
Problems

Go Buffered Channels: Producer-Consumer Simulation

In concurrent programming, channels are fundamental for safe communication between goroutines. Buffered channels provide a mechanism to send values without requiring an immediate receiver, decoupling the sender and receiver and potentially improving performance. This challenge focuses on understanding and utilizing buffered channels to implement a common producer-consumer pattern.

Problem Description

Your task is to simulate a simple producer-consumer scenario using Go's buffered channels. You will create two goroutines: a producer that generates a sequence of numbers and sends them to a buffered channel, and a consumer that receives these numbers from the channel and processes them. The key requirement is to use a buffered channel to allow the producer to send a certain number of values without blocking, even if the consumer is not immediately ready to receive them.

Key Requirements:

  • Create a buffered channel with a specific capacity.
  • Implement a producer goroutine that sends a predefined number of integers to the buffered channel.
  • Implement a consumer goroutine that receives all integers from the buffered channel and prints them.
  • Ensure the main goroutine waits for both the producer and consumer to finish their work.
  • Close the channel by the producer once all data has been sent to signal to the consumer that no more data will arrive.

Expected Behavior:

The output should show the numbers being consumed, potentially in an order that reflects the buffering. The program should terminate cleanly after all numbers are produced and consumed.

Edge Cases to Consider:

  • Channel Capacity: What happens if the producer tries to send more values than the buffer capacity allows before the consumer has made space? (It should block).
  • Empty Channel: What happens when the consumer tries to read from an empty channel after it has been closed? (It will receive the zero value and a false boolean).

Examples

Example 1:

Input:
Number of items to produce: 5
Channel buffer capacity: 3

Output:
Produced: 0
Produced: 1
Produced: 2
Consumed: 0
Consumed: 1
Consumed: 2
Produced: 3
Consumed: 3
Produced: 4
Consumed: 4

Explanation: The producer starts sending numbers 0 through 4. The consumer starts receiving. When the buffer reaches its capacity of 3 (numbers 0, 1, 2), the producer blocks on sending 3 until the consumer has read at least one value. The order of production and consumption can interleave due to the buffer.

Example 2:

Input:
Number of items to produce: 10
Channel buffer capacity: 1

Output:
Produced: 0
Consumed: 0
Produced: 1
Consumed: 1
Produced: 2
Consumed: 2
... (continues until 9 is produced and consumed)
Produced: 9
Consumed: 9

Explanation: With a buffer capacity of 1, the producer and consumer are more tightly coupled. The producer can only send one item ahead of the consumer. This is effectively a "hand-off" mechanism.

Example 3: (Edge case: Buffer larger than total items)

Input:
Number of items to produce: 3
Channel buffer capacity: 5

Output:
Produced: 0
Produced: 1
Produced: 2
Consumed: 0
Consumed: 1
Consumed: 2

Explanation: When the buffer capacity is larger than or equal to the total number of items to produce, the producer can send all items without ever blocking. The consumer then processes them sequentially.

Constraints

  • The number of items to produce will be an integer between 1 and 1000.
  • The channel buffer capacity will be an integer between 1 and 100.
  • The program must use goroutines and channels.
  • The sync.WaitGroup should be used to ensure the main goroutine waits for all other goroutines to complete.
  • The channel must be closed by the producer after all items are sent.

Notes

  • Consider how to handle receiving from a closed channel in the consumer. The for range loop over a channel is a idiomatic way to handle this.
  • Think about how to signal completion from the producer and consumer goroutines back to the main goroutine. sync.WaitGroup is the standard tool for this.
  • Experiment with different buffer sizes to observe the behavior.
Loading editor...
go