Default SynchronizationContext vs Default TaskScheduler

Question

This is going to be a bit long, so please bear with me. I was thinking that the behavior of the default task scheduler (`ThreadPoolTaskScheduler`) is very similar to that of the default "`ThreadPool`" `SynchronizationContext` (the latter can be referenced implicitly via `await` or explicitly via `TaskScheduler.FromCurrentSynchronizationContext()`). They both schedule tasks to be executed on a random `ThreadPool` thread. In fact, `SynchronizationContext.Post` merely calls `ThreadPool.QueueUserWorkItem`. However, there is a subtle but important difference in how `TaskCompletionSource.SetResult` works, when used from a task queued on the default `SynchronizationContext`. Here's a simple console app illustrating it: ``` using System; using System.Threading; using System.Threading.Tasks; namespace ConsoleTcs { class Program { static async Task TcsTest(TaskScheduler taskScheduler) { var tcs = new TaskCompletionSource<bool>(); var task = Task.Factory.StartNew(() => { Thread.Sleep(1000); Cons…

Accepted Answer

When you start diving this deep into the implementation details, it's important to differentiate between documented/reliable behavior and undocumented behavior. Also, it's not really considered proper to have `SynchronizationContext.Current` set to `new SynchronizationContext()`; some types in .NET treat `null` as the default scheduler, and other types treat `null` or `new SynchronizationContext()` as the default scheduler.

When you `await` an incomplete `Task`, the `TaskAwaiter` by default captures the current `SynchronizationContext` - unless it is `null` (or its `GetType` returns `typeof(SynchronizationContext)`), in which case the `TaskAwaiter` captures the current `TaskScheduler`. This behavior is mostly documented (the `GetType` clause is not AFAIK). However, please note that this describes the behavior of `TaskAwaiter`, not `TaskScheduler.Default` or `TaskFactory.StartNew`.

After the context (if any) is captured, then `await` schedules a continuation. This continuation is scheduled using `ExecuteSynchronously`, as described on my blog (this behavior is undocumented). However, do note that `ExecuteSynchronously` does not always execute synchronously; in particular, if a continuation has a task scheduler, it will only request to execute synchronously on the current thread, and the task scheduler has the option to refuse to execute it synchronously (also undocumented).

Finally, note that a `TaskScheduler` can be requested to execute a task synchronously, but a `SynchronizationContext` cannot. So, if the `await` captures a custom `SynchronizationContext`, then it must always execute the continuation asynchronously.

So, in your original Test #1:

- `StartNew` starts a new task with the default task scheduler (on thread 10).

- `SetResult` synchronously executes the continuation set by `await tcs.Task`.

- At the end of the `StartNew` task, it synchronously executes the continuation set by `await task`.

In your original Test #2:

- `StartNew` starts a new task with a task scheduler wrapper for a default-constructed synchronization context (on thread 10). Note that the task on thread 10 has `TaskScheduler.Current` set to a `SynchronizationContextTaskScheduler` whose `m_synchronizationContext` is the instance created by `new SynchronizationContext()`; however, that thread's `SynchronizationContext.Current` is `null`.

- `SetResult` attempts to execute the `await tcs.Task` continuation synchronously on the current task scheduler; however, it cannot because `SynchronizationContextTaskScheduler` sees that thread 10 has a `SynchronizationContext.Current` of `null` while it is requiring a `new SynchronizationContext()`. Thus, it schedules the continuation asynchronously (on thread 11).

- A similar situation happens at the end of the `StartNew` task; in this case, I believe it's coincidental that the `await task` continues on the same thread.

In conclusion, I must emphasize that depending on undocumented implementation details is not wise. If you want to have your `async` method continue on a thread pool thread, then wrap it in a `Task.Run`. That will make the intent of your code much clearer, and also make your code more resilient to future framework updates. Also, don't set `SynchronizationContext.Current` to `new SynchronizationContext()`, since the handling of that scenario is inconsistent.

Default SynchronizationContext vs Default TaskScheduler

Solution

Problem