➡️ Channels in C# — Building High-Throughput Async Pipelines
  • .NET
  • Concurrency
  • Async
  • Architecture
Apr 12, 2021

💡 Why Channels?

Async/await made asynchronous code elegant. But in real systems, we often need to continuously move data between components — not just await a single task.

  • A web server queues background jobs.
  • A telemetry system streams metrics.
  • A crawler pushes URLs to workers.

What we need is a non-blocking, thread-safe, asynchronous queue that connects producers and consumers.

That’s exactly what System.Threading.Channels provides — a built-in, high-performance async pipeline abstraction for .NET.

🧠 The Problem Channels Solve

Before Channels, you might have used:

  • BlockingCollection<T> — blocks threads; not async-friendly
  • ConcurrentQueue<T> + SemaphoreSlim — verbose and error-prone
  • Custom queues — difficult to handle backpressure or graceful shutdown

These patterns work, but they either waste threads or get complicated fast when you add multiple producers, consumers, and cancellation logic.

Channels fix that by offering:

  • ✅ Asynchronous reads/writes
  • ✅ Backpressure (via bounded capacity)
  • ✅ Graceful completion
  • ✅ Built-in cancellation
  • ✅ Lock-free, high performance

⚙️ Channel Basics

A channel is a pipe between two sides, producer and consumer(s).

                        ┌───────────┐
                        │ Producer  │
                        └───────────┘
                              │
                              ▼
                    ┌─────────────────────┐
                    │     Channel<T>      │
                    └─────────────────────┘
                    │          │          │
                    ▼          ▼          ▼
            ┌───────────┐ ┌───────────┐ ┌───────────┐
            │ Consumer1 │ │ Consumer2 │ │ Consumer3 │
            └───────────┘ └───────────┘ └───────────┘
  • ChannelWriter<T> → used by producers to write messages
  • ChannelReader<T> → used by consumers to read messages

Basic usage:

var channel = Channel.CreateUnbounded<int>();

// Producer
_ = Task.Run(async () =>
{
    for (int i = 0; i < 10; i++)
        await channel.Writer.WriteAsync(i);

    channel.Writer.Complete(); // signal that no more items will come
});

// Consumer
await foreach (var item in channel.Reader.ReadAllAsync())
{
    Console.WriteLine($"Received {item}");
}

Both sides are fully asynchronous — no blocking, no polling.

Channel Types

Unbounded

var channel = Channel.CreateUnbounded<int>();

A channel with no fixed limit on the number of items it can store. Items are added instantly to an internal list without blocking the producer, regardless of how fast the consumer is reading.

Pros:

  • Highest Throughput: The producer (writer) is never blocked, ensuring the fastest possible rate of insertion.
  • Simplicity: It’s the simplest channel to implement and reason about, as you don’t need to worry about buffer capacity.

Cons:

  • Memory Risk: It can consume an unlimited amount of memory if the consumer (reader) is slower than the producer. This is a critical risk that can lead to application crashes due to out-of-memory exceptions.

When to Use

  • When writing non-critical application logs or diagnostics where speed is paramount and temporarily falling behind is acceptable, but blocking the main application thread is not. Since a lost log entry is generally not catastrophic, the risk of temporary high memory usage is tolerated for guaranteed producer speed.

When Not to Use

  • When the items represent valuable, stateful, or long-lived data (e.g., customer orders, financial transactions, or large file transfer chunks). Using an Unbounded channel here creates a time bomb: if a transient downstream failure occurs, the producer will continue dumping data, causing the application to eventually crash from an Out-Of-Memory exception instead of applying safe backpressure.

Bounded - Wait/Block

var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(capacity: 10)
{
    FullMode = BoundedChannelFullMode.Wait
});

A channel with a fixed maximum capacity. When the buffer becomes full, the producer will asynchronously wait for space to become available before the write operation completes.

Pros:

  • No Data Loss: Every item written to the channel is guaranteed to be eventually read.
  • Built-in Backpressure: It automatically slows down a fast producer when the consumer is lagging, protecting system resources and preventing memory overflows.

Cons:

  • Producer Blocking: The producer is forced to wait, which can potentially lead to lower overall throughput or thread pool starvation if many writers are blocked simultaneously.

When to Use

  • For reliable critical task processing queues, such as processing customer orders, saving data to a slow database, or sending emails. You must ensure that every single item is handled, and applying backpressure is the best way to prevent the upstream system from crashing the downstream one.

When Not to Use

  • In scenarios where the producer is highly sensitive to latency and cannot afford to wait, such as handling high-frequency stock market data or real-time user input from a game controller.

Bounded - Drop Oldest

var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(capacity: 10)
{
    FullMode = BoundedChannelFullMode.DropOldest
});

A channel with a fixed maximum capacity. When full, attempting to add a new item causes the oldest item currently in the buffer to be dropped to make room for the new one.

Pros:

  • Memory Safety: The maximum memory usage is guaranteed to be fixed, regardless of the load.
  • Prioritizes Newest Data: Ideal for scenarios like real-time monitoring where the latest data point is always the most relevant, and stale data can be discarded.

Cons:

  • Data Loss: Under sustained high load, data will be silently discarded. This is unacceptable for systems that require guaranteed message delivery.

When to Use

  • For real-time monitoring dashboards or telemetry processing. If your system is collecting sensor readings (e.g., CPU temperature, network latency), you only care about the most recent values. If the processing queue fills up, dropping the minute-old data to make room for the new reading is the desired behavior.

When Not to Use

  • For any type of financial transaction, persistent storage commands, or message streams where the order of operations is crucial and dropping an item would result in an inconsistent state.

Bounded - Drop Newest

var channel = Channel.CreateBounded<int>(new BoundedChannelOptions(capacity: 10)
{
    FullMode = BoundedChannelFullMode.DropNewest
});

A channel with a fixed maximum capacity. When full, an attempt to add a new item is immediately failed, and the new item is dropped.

Pros:

  • Memory Safety: The maximum memory usage is fixed.
  • Protects Critical Data: Ensures that older, potentially partially processed, or more critical data is always kept and sent to the consumer.

Cons:

  • Data Loss: The newest item is discarded. The producer must handle the failure of the write operation. This is rarely used unless the older items are significantly more important than new ones.

When to Use

  • In configuration or state initialization pipelines where the first messages contain the fundamental setup (e.g., security keys, database connection strings) that are essential for the downstream consumer to start. If the consumer is slow, you absolutely must process the initial, mandatory setup items. A flood of new, non-essential status updates or optional changes that arrive later can be dropped, ensuring the core setup is not lost or delayed.

When Not to Use

  • In almost all typical message queues, especially those handling time-series data, updates, or commands. If you drop a newer message, you risk the consumer processing an obsolete state. For example, if the queue contains user mouse clicks, dropping the latest click means the user’s action is missed, but their earlier, less relevant clicks are still processed. If the newest data invalidates the old data, this mode is not suitable.

Rendezvous

var options = new BoundedChannelOptions(capacity: 1)
{
    FullMode = BoundedChannelFullMode.Wait
};
var channel = Channel.CreateBounded<int>(options);

A specialized zero-buffer channel (achieved most commonly with capacity=1 and BoundedChannelFullMode.Wait). The producer must wait for a consumer to be ready to read before the item is successfully written. The item is passed directly from writer to reader without being buffered, acting as a synchronous handshake.

Pros:

  • Minimal Memory Overhead: Requires virtually no memory for internal buffering.
  • Tight Coupling: Excellent for synchronous-like communication where a producer must confirm an item was instantly picked up by a consumer.

Cons:

  • High Latency & Low Throughput: Both the producer and consumer must be active simultaneously. This dependency severely limits the speed and throughput of the process.

When to Use

  • Implementing a custom, one-at-a-time rate-limiting or concurrency control mechanism between two specific components, where the passing of the item serves as both the data and the permission to proceed.

When Not to Use

  • The entire purpose of a channel is often to decouple the producer and consumer. A Rendezvous channel does the opposite—it tightly couples them. If you need systems to operate independently at their own paces, this channel is not suitable.

Advanced Channel Option

SingleWriter

Tells the channel that only a single producer (writer) will ever write to the channel concurrently. Setting this to true allows the channel to use a simpler, non-thread-safe internal data structure for writing. Since the compiler knows only one writer exists, it can eliminate the locking/synchronization overhead typically required for concurrent writes.

SingleReader

Tells the channel that only a single consumer (reader) will ever read from the channel concurrently. Similar to SingleWriter, setting this to true allows the channel to use simpler, more efficient internal logic for reading. It removes the need for locking/synchronization when multiple consumers might try to dequeue an item simultaneously.

AllowSynchronousContinuations

Controls whether asynchronous continuations (code scheduled to run after an await completes) can execute synchronously. If set to true, when a writer completes a task that a reader is awaiting (or vice versa), the subsequent code (the “continuation”) might run immediately on the thread that completed the write/read operation. If set to false (the default), the continuation is always scheduled to run later, usually on the thread pool.

✋ Completing a Channel

Completing a channel is the mechanism by which a producer signals to all consumers that no further items will ever be written. This allows consumers to exit their read loops gracefully and prevents them from waiting indefinitely.

You signal completion using the Complete() method on the channel’s writer.

using System.Threading.Channels;

var channel = Channel.CreateBounded<int>(5);
var writer = channel.Writer;

// Producer writes items
await writer.WriteAsync(1);
await writer.WriteAsync(2);

// Producer signals completion
writer.Complete();

// A consumer can now read remaining items and exit gracefully
await foreach (var item in channel.Reader.ReadAllAsync())
{
    Console.WriteLine($"Read: {item}");
}

// After the loop, the consumer knows no more data is coming.

Completion with an Error

If the channel is being completed because a critical error occurred, you should pass the exception to the Complete() method.

using System.Threading.Channels;

var channel = Channel.CreateBounded<int>(5);
var writer = channel.Writer;

// Producer writes items
await writer.WriteAsync(1);
await writer.WriteAsync(2);

// Producer signals completion with error
writer.Complete(new InvalidOperationException("Critical error"));

try
{
    // A consumer processes items 1 and 2 and then receives an exception
    await foreach (var item in channel.Reader.ReadAllAsync())
    {
        Console.WriteLine($"Read: {item}");
    }
}
// the exception will be caught here
catch (InvalidOperationException ex)
{
    Console.WriteLine(ex);
}

🏁 Final Words

Let’s wrap this up. If you’ve ever struggled with old-school queues that lock up threads or just felt like your async code was missing a crucial piece, channels are the answer.

Think of them as the perfect, high-speed plumbing for your async C# application. They don’t just move data, they handle the heavy lifting of flow control and thread safety for you.