"await Task.Yield()" and its alternatives

Question

If I need to postpone code execution until after a future iteration of the UI thread message loop, I could do so something like this:

await Task.Factory.StartNew(     () => {         MessageBox.Show("Hello!");     },     CancellationToken.None,     TaskCreationOptions.None,     TaskScheduler.FromCurrentSynchronizationContext()); 

This would be similar to await Task.Yield(); MessageBox.Show("Hello!");, besides I'd have an option to cancel the task if I wanted to.

In case with the default synchronization context, I could similarly use await Task.Run to continue on a pool thread.

In fact, I like Task.Factory.StartNew and Task.Run more than Task.Yield, because they both explicitly define the scope for the continuation code.

So, in what situations await Task.Yield() is actually useful?

Answer 1

Consider the case when you want your async task to return a value.

Existing synchronous method:

public int DoSomething() {     return SomeMethodThatReturnsAnInt(); } 

To make async, add async keyword and change return type:

public async Task<int> DoSomething() 

To use Task.Factory.StartNew(), change the one-line body of the method to:

// start new task var task = Task<int>.Factory.StartNew(     () => {         return SomeMethodThatReturnsAnInt();     },     CancellationToken.None,     TaskCreationOptions.None,     TaskScheduler.FromCurrentSynchronizationContext() );  // await task, return control to calling method await task;  // return task result return task.Result; 

vs. adding a single line if you use await Task.Yield()

// this returns control to the calling method await Task.Yield();  // otherwise synchronous method scheduled for async execution by the  // TaskScheduler of the calling thread return SomeMethodThatReturnsAnInt(); 

The latter is far more concise, readable, and really doesn't change the existing method much.

Answer 2

Task.Yield() is great for "punching a hole" in an otherwise synchronous part of an async method.

Personally I've found it useful in cases where I have a self-cancelling async method (one which manages its own corresponding CancellationTokenSource and cancels the previously created instance on each subsequent call) that can be called multiple times within an extremely short time period (i.e. by interdependent UI elements' event handlers). In such a situation using Task.Yield() followed by an IsCancellationRequested check as soon as the CancellationTokenSource is swapped out can prevent doing potentially expensive work whose results will end up discarded anyway.

Here's an example where only the last queued call to SelfCancellingAsync gets to perform expensive work and run to completion.

using System; using System.Threading; using System.Threading.Tasks;  namespace TaskYieldExample {     class Program     {         private static CancellationTokenSource CancellationTokenSource;          static void Main(string[] args)         {             SelfCancellingAsync();             SelfCancellingAsync();             SelfCancellingAsync();              Console.ReadLine();         }          private static async void SelfCancellingAsync()         {             Console.WriteLine("SelfCancellingAsync starting.");              var cts = new CancellationTokenSource();             var oldCts = Interlocked.Exchange(ref CancellationTokenSource, cts);              if (oldCts != null)             {                 oldCts.Cancel();             }              // Allow quick cancellation.             await Task.Yield();              if (cts.IsCancellationRequested)             {                 return;             }              // Do the "meaty" work.             Console.WriteLine("Performing intensive work.");              var answer = await Task                 .Delay(TimeSpan.FromSeconds(1))                 .ContinueWith(_ => 42, TaskContinuationOptions.ExecuteSynchronously);              if (cts.IsCancellationRequested)             {                 return;             }              // Do something with the result.             Console.WriteLine("SelfCancellingAsync completed. Answer: {0}.", answer);         }     } } 

The goal here is to allow the code which executes synchronously on the same SynchronizationContext immediately after the non-awaited call to the async method returns (when it hits its first await) to change the state that affects the execution of the async method. This is throttling much like that achieved by Task.Delay (i'm talking about a non-zero delay period here), but without the actual, potentially noticeable delay, which can be unwelcome in some situations.