Go Message Queue Implementation

This challenge asks you to build a foundational message queue system in Go. A message queue is a crucial component in distributed systems, enabling asynchronous communication between different parts of an application or between entirely separate applications. Implementing one will give you practical experience with concurrency, channels, and managing shared resources in Go.

Problem Description

Your task is to create a thread-safe message queue in Go that supports adding messages and retrieving them. The queue should handle multiple producers (adding messages) and multiple consumers (retrieving messages) concurrently.

Key Requirements:

1. Thread-Safety: The queue must be safe for concurrent access by multiple goroutines.
2. FIFO (First-In, First-Out): Messages must be retrieved in the same order they were added.
3. Enqueue Operation: A method to add a message to the queue.
4. Dequeue Operation: A method to remove and return a message from the queue.
5. Blocking Dequeue: If the queue is empty, Dequeue should block until a message becomes available.
6. Graceful Shutdown: The queue should have a mechanism to be closed, signaling to consumers that no more messages will be added. When closed and empty, Dequeue should return an error or a specific signal.

Expected Behavior:

• Producers can add messages at any time.
• Consumers can request messages. If messages are available, they are returned immediately.
• If no messages are available, consumers will wait until a message is enqueued or the queue is closed.
• Once Close is called, no new messages can be enqueued.
• After Close is called and all existing messages are dequeued, subsequent Dequeue calls should indicate that the queue is closed.

Edge Cases to Consider:

• Enqueuing after closing the queue.
• Dequeuing from an empty queue.
• Dequeuing from a queue that has been closed and emptied.
• Multiple producers and consumers operating simultaneously.

Examples

Example 1:

• Scenario: A single producer enqueues two messages, followed by a single consumer dequeuing them.
• Input (Conceptual):
  • queue.Enqueue("hello")
  • queue.Enqueue("world")
  • msg1 := queue.Dequeue()
  • msg2 := queue.Dequeue()
• Output:
  • msg1 should be "hello"
  • msg2 should be "world"
• Explanation: Messages are processed in the order they are enqueued.

Example 2:

• Scenario: Multiple producers enqueue messages, and a single consumer dequeues them.
• Input (Conceptual):
  • producer1.Enqueue("msg A")
  • producer2.Enqueue("msg B")
  • producer1.Enqueue("msg C")
  • consumer1.Dequeue() (called multiple times)
• Output: The consumer will receive "msg A", then "msg B", then "msg C". The specific goroutine that enqueued a message is not relevant to the dequeue order.
• Explanation: Demonstrates FIFO behavior under concurrent enqueue operations.

Example 3:

• Scenario: A consumer attempts to dequeue from an empty queue, followed by a message being enqueued, and then the queue being closed and emptied.
• Input (Conceptual):
  • go func() { msg, err := queue.Dequeue(); /* handle msg/err */ }() (This goroutine will block initially)
  • queue.Enqueue("first message") (This unblocks the consumer)
  • queue.Close()
  • go func() { msg, err := queue.Dequeue(); /* handle msg/err */ }() (This goroutine will receive the remaining message and then an "empty/closed" signal)
  • go func() { msg, err := queue.Dequeue(); /* handle msg/err */ }() (This goroutine will immediately receive an "empty/closed" signal)
• Output:
  • The first Dequeue will receive "first message".
  • The second Dequeue will receive an error indicating the queue is closed or empty.
  • The third Dequeue will receive an error indicating the queue is closed or empty.
• Explanation: Shows blocking behavior, unblocking on enqueue, and graceful shutdown with error signaling.

Constraints

• The message type can be interface{} to allow for any data type.
• The queue should not have a fixed capacity limit, but consider how you would implement one if needed (though not required for this challenge).
• Implement the queue using Go's built-in channels and potentially sync.Mutex if necessary for auxiliary data.
• Your implementation should aim for reasonable performance for typical use cases.

Notes

• Consider using Go's channels as the primary mechanism for communication and synchronization.
• A sync.Mutex might be useful for protecting shared state that isn't directly managed by channels (e.g., a flag indicating if the queue is closed).
• Think about how to signal to consumers that the queue has been closed and no more messages are coming. This is critical for preventing goroutine leaks.
• A common pattern for graceful shutdown with channels involves closing the channel itself, or using a separate context.Context or done channel.