Question

I’m currently working on a largely asynchronous application which uses TAP throughout. Every class which has methods for spawning Tasks also has a TaskScheduler injected into it. This allows us to perform explicit scheduling of tasks, which as I understand, is not the way Microsoft are going with the Async CTP.

The only issue I have with the new approach (implicit scheduling) is that our previous philosophy has always been “we know the continuation will always specify their task scheduler, so we don’t need to worry about what context we complete the task on”.

Moving away from that does worry us slightly just because it has worked extremely well in terms of avoiding subtle threading errors, because for every bit of code we can see that the coder has remembered to consider what thread he’s on. If they missed specifying the task scheduler, it’s a bug.

Question 1: Can anyone reassure me that the implicit approach is a good idea? I see so many issues being introduced by ConfigureAwait(false) and explicit scheduling in legacy/third party code. How can I be sure my ‘await-ridden’ code is always running on the UI thread, for example?

Question 2: So, assuming we remove all TaskScheduler DI from our code and begin to use implicit scheduling, how do we then set the default task scheduler? What about changing scheduler midway through a method, just before awaiting an expensive method, and then setting it back again afterward?

(p.s. I have already read http://msmvps.com/blogs/jon_skeet/archive/2010/11/02/configuring-waiting.aspx)

Answer 1

I’ll take a shot at answering. 😉

Question 1: Can anyone reassure me that the implicit approach is a good idea? I see so many issues being introduced by ConfigureAwait(false) and explicit scheduling in legacy/third party code. How can I be sure my ‘await-ridden’ code is always running on the UI thread, for example?

The rules for ConfigureAwait(false) are pretty simple: use it if the rest of your method can be run on the threadpool, and don’t use it if the rest of your method must run in a given context (e.g., UI context).

Generally speaking, ConfigureAwait(false) should be used by library code, and not by UI-layer code (including UI-type layers such as ViewModels in MVVM). If the method is partially-background-computation and partially-UI-updates, then it should be split into two methods.

Question 2: So, assuming we remove all TaskScheduler DI from our code and begin to use implicit scheduling, how do we then set the default task scheduler?

async/await does not normally use TaskScheduler; they use a “scheduling context” concept. This is actually SynchronizationContext.Current, and falls back to TaskScheduler.Current only if there is no SynchronizationContext. Substituting your own scheduler can therefore be done using SynchronizationContext.SetSynchronizationContext. You can read more about SynchronizationContext in this MSDN article on the subject.

The default scheduling context should be what you need almost all of the time, which means you don’t need to mess with it. I only change it when doing unit tests, or for Console programs / Win32 services.

What about changing scheduler midway through a method, just before awaiting an expensive method, and then setting it back again afterward?

If you want to do an expensive operation (presumably on the threadpool), then await the result of TaskEx.Run.

If you want to change the scheduler for other reasons (e.g., concurrency), then await the result of TaskFactory.StartNew.

In both of these cases, the method (or delegate) is run on the other scheduler, and then the rest of the method resumes in its regular context.

Ideally, you want each async method to exist within a single execution context. If there are different parts of the method that need different contexts, then split them up into different methods. The only exception to this rule is ConfigureAwait(false), which allows a method to start on an arbitrary context and then revert to the threadpool context for the remainder of its execution. ConfigureAwait(false) should be considered an optimization (that’s on by default for library code), not as a design philosophy.

Here’s some points from my “Thread is Dead” talk that I think may help you with your design:

• Follow the Task-Based Asynchronous Pattern guidelines.
• As your code base becomes more asynchronous, it will become more functional in nature (as opposed to traditionally object-oriented). This is normal and should be embraced.
• As your code base becomes more asynchronous, shared-memory concurrency gradually evolves to message-passing concurrency (i.e., ConcurrentExclusiveSchedulerPair is the new ReaderWriterLock).