I'm using async/await and Task
a lot but have never been using Task.Yield()
and to be honest even with all the explanations I do not understand why I would need this method.
Can somebody give a good example where Yield()
is required?
setTimeout(_, 0)
.
When you use async
/await
, there is no guarantee that the method you call when you do await FooAsync()
will actually run asynchronously. The internal implementation is free to return using a completely synchronous path.
If you're making an API where it's critical that you don't block and you run some code asynchronously, and there's a chance that the called method will run synchronously (effectively blocking), using await Task.Yield()
will force your method to be asynchronous, and return control at that point. The rest of the code will execute at a later time (at which point, it still may run synchronously) on the current context.
This can also be useful if you make an asynchronous method that requires some "long running" initialization, ie:
private async void button_Click(object sender, EventArgs e)
{
await Task.Yield(); // Make us async right away
var data = ExecuteFooOnUIThread(); // This will run on the UI thread at some point later
await UseDataAsync(data);
}
Without the Task.Yield()
call, the method will execute synchronously all the way up to the first call to await
.
Internally, await Task.Yield()
simply queues the continuation on either the current synchronization context or on a random pool thread, if SynchronizationContext.Current
is null
.
It is efficiently implemented as custom awaiter. A less efficient code producing the identical effect might be as simple as this:
var tcs = new TaskCompletionSource<bool>();
var sc = SynchronizationContext.Current;
if (sc != null)
sc.Post(_ => tcs.SetResult(true), null);
else
ThreadPool.QueueUserWorkItem(_ => tcs.SetResult(true));
await tcs.Task;
Task.Yield()
can be used as a short-cut for some weird execution flow alterations. For example:
async Task DoDialogAsync()
{
var dialog = new Form();
Func<Task> showAsync = async () =>
{
await Task.Yield();
dialog.ShowDialog();
}
var dialogTask = showAsync();
await Task.Yield();
// now we're on the dialog's nested message loop started by dialog.ShowDialog
MessageBox.Show("The dialog is visible, click OK to close");
dialog.Close();
await dialogTask;
// we're back to the main message loop
}
That said, I can't think of any case where Task.Yield()
cannot be replaced with Task.Factory.StartNew
w/ proper task scheduler.
See also:
"await Task.Yield()" and its alternatives
Task.Yield - real usages?
var dialogTask = await showAsync();
?
var dialogTask = await showAsync()
won't compile because the await showAsync()
expression doesn't return a Task
(unlike it does without await
). That said, if you do await showAsync()
, the execution after it will be resumed only after the dialog has been closed, that's how it's different. That's because window.ShowDialog
is a synchronous API (despite it still pumps messages). In that code, I wanted to continue while the dialog is still shown.
await Task.Yield()
have the same effect as await Task.Delay(1)
?
await Task.Delay(1)
over await Task.Yield()
?
One use of Task.Yield()
is to prevent a stack overflow when doing async recursion. Task.Yield()
prevents syncronous continuation. Note, however, that this can cause an OutOfMemory exception (as noted by Triynko). Endless recursion is still not safe and you're probably better off rewriting the recursion as a loop.
private static void Main()
{
RecursiveMethod().Wait();
}
private static async Task RecursiveMethod()
{
await Task.Delay(1);
//await Task.Yield(); // Uncomment this line to prevent stackoverlfow.
await RecursiveMethod();
}
await Task.Delay(1)
is enough to prevent it. (Console App, .NET Core 3.1, C# 8)
await Task.Delay(1);
and await Task.Yield();
would do almost exactly the same thing?
Task.Yield()
is like a counterpart of Thread.Yield()
in async-await but with much more specific conditions. How many times do you even need Thread.Yield()
? I will answer the title "when would you use Task.Yield()
" broadly first. You would when the following conditions are fulfilled:
want to return the control to the async context (suggesting the task scheduler to execute other tasks in the queue first)
need to continue in the async context
prefer to continue immediately when the task scheduler is free
do not want to be cancelled
prefer shorter code
The term "async context" here means "SynchronizationContext first then TaskScheduler". It was used by Stephen Cleary.
Task.Yield()
is approximately doing this (many posts get it slightly wrong here and there):
await Task.Factory.StartNew(
() => {},
CancellationToken.None,
TaskCreationOptions.PreferFairness,
SynchronizationContext.Current != null?
TaskScheduler.FromCurrentSynchronizationContext():
TaskScheduler.Current);
If any one of the conditions is broken, you need to use other alternatives instead.
If the continuation of a task should be in Task.DefaultScheduler
, you normally use ConfigureAwait(false)
. On the contrary, Task.Yield()
gives you an awaitable not having ConfigureAwait(bool)
. You need to use the approximated code with TaskScheduler.Default
.
If Task.Yield()
obstructs the queue, you need to restructure your code instead as explained by noseratio.
If you need the continuation to happen much later, say, in the order of millisecond, you would use Task.Delay
.
If you want the task to be cancellable in the queue but do not want to check the cancellation token nor throw an exception yourself, you need to use the approximated code with a cancellation token.
Task.Yield()
is so niche and easily dodged. I only have one imaginary example by mixing my experience. It is to solve an async dining philosopher problem constrained by a custom scheduler. In my multi-thread helper library InSync, it supports unordered acquisitions of async locks. It enqueues an async acquisition if the current one failed. The code is here. It needs ConfigureAwait(false)
as a general purpose library so I need to use Task.Factory.StartNew
. In a closed source project, my program needs to execute significant synchronous code mixed with async code with
a high thread priority for semi-realtime work
a low thread priority for some background work
a normal thread priority for UI
Thus, I need a custom scheduler. I could easily imagine some poor developers somehow need to mix sync and async code together with some special schedulers in a parallel universe (one universe probably does not contain such developers); but why wouldn't they just use the more robust approximated code so they do not need to write a lengthy comment to explain why and what it does?
Task.Yield()
may be used in mock implementations of async methods.
Success story sharing
await Task.Yield()
forces the method to be async, why would we bother writing "real" async code? Imagine a heavy sync method. To make it async, just addasync
andawait Task.Yield()
in the beginning and magically, it will be async? That would pretty much be like wrapping all sync code intoTask.Run()
and create a fake async method.Task.Run
to implement it,ExecuteFooOnUIThread
will run on the thread pool, not the UI thread. Withawait Task.Yield()
, you force it to be asynchronous in a way that the subsequent code is still run on the current context (just at a later point in time). It's not something you'd normally do, but it is nice that there is the option if it's required for some strange reason.ExecuteFooOnUIThread()
was very long running, it would still block the UI thread for a long time at some point and make the UI unresponsive, is that correct?