Introduction

Synchronous continuations become a problem when completing one Task unexpectedly runs more work inline on the same thread. In .NET, the most important distinction is whether you are consuming someone else's task or producing the task yourself, because you can only reliably control continuation behavior at the point where the task is created.

The real fix for producer-created tasks

If you are using TaskCompletionSource<T>, the standard fix is to create it with TaskCreationOptions.RunContinuationsAsynchronously. That tells .NET not to run registered continuations inline when the task is completed.

1using System;
2using System.Threading.Tasks;
3
4public sealed class Signal
5{
6    private readonly TaskCompletionSource<string> _tcs =
7        new(TaskCreationOptions.RunContinuationsAsynchronously);
8
9    public Task<string> WaitAsync() => _tcs.Task;
10
11    public void Complete(string value)
12    {
13        _tcs.TrySetResult(value);
14    }
15}

Without that option, a call to TrySetResult can end up running downstream continuations synchronously on the completing thread. That can create surprising reentrancy, latency spikes, and even deadlock-like behavior in producer-consumer pipelines.

What ConfigureAwait(false) does and does not do

ConfigureAwait(false) is useful, but it solves a different problem. It tells an await not to capture the current synchronization context. It does not force the antecedent task to dispatch continuations asynchronously.

1public async Task<int> GetValueAsync(Task<int> source)
2{
3    int value = await source.ConfigureAwait(false);
4    return value * 2;
5}

This is good library code because it avoids unnecessary context capture. It does not guarantee that the continuation behind await will never run inline at completion time.

If you do not own the task, you cannot fully change it

This is the part many answers skip. If another component already created the task, there is no general-purpose wrapper that retroactively changes how that task completes. You can move later work to the thread pool with Task.Run, but that is not the same as changing the task's completion semantics.

In other words:

• if you own the task source, use RunContinuationsAsynchronously
• if you only await the task, you can control context capture but not the task's internal continuation policy

That is why TaskCompletionSource<T> is usually the center of this discussion.

A small demonstration

The code below completes a task and keeps the continuation off the producer thread:

1using System;
2using System.Threading;
3using System.Threading.Tasks;
4
5public static class Demo
6{
7    public static async Task Main()
8    {
9        var tcs = new TaskCompletionSource<int>(
10            TaskCreationOptions.RunContinuationsAsynchronously);
11
12        Task consumer = tcs.Task.ContinueWith(task =>
13        {
14            Console.WriteLine($"Continuation thread: {Thread.CurrentThread.ManagedThreadId}");
15        });
16
17        Console.WriteLine($"Producer thread: {Thread.CurrentThread.ManagedThreadId}");
18        tcs.SetResult(42);
19
20        await consumer;
21    }
22}

The point is not that every continuation must run on a new thread. The point is that completion should not inline arbitrary continuation work onto the thread that calls SetResult.

Related cases

If you are implementing high-performance async primitives with ValueTask, the same idea appears in ManualResetValueTaskSourceCore<T> through its RunContinuationsAsynchronously property. The concept is stable across both APIs: producer-controlled tasks can opt into asynchronous continuation dispatch.

Common Pitfalls

• Using ConfigureAwait(false) and expecting it to prevent synchronous continuations. It only avoids context capture.
• Passing the wrong enum to TaskCompletionSource<T>. The constructor takes TaskCreationOptions, not TaskContinuationOptions.
• Wrapping work in Task.Run just to hide the problem. That changes scheduling, not the source task's behavior.
• Assuming you can retrofit continuation policy onto a task created by another library.
• Forgetting that inline continuations can create reentrancy and long tail latency even when there is no deadlock.

Summary

• If you create the task, use TaskCreationOptions.RunContinuationsAsynchronously.
• 'ConfigureAwait(false) is useful for context capture, but it does not solve inline completion behavior.'
• You cannot generally change continuation semantics after a task has already been created.
• 'TaskCompletionSource<T> is the usual place where this problem and its fix appear.'
• Treat synchronous continuations as a producer-side design issue, not just a consumer-side scheduling issue.