ChatGPT解决这个技术问题 Extra ChatGPT

When would I use Task.Yield()?

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?

For any js developers out here, this is equivalent to setTimeout(_, 0).

R
Reed Copsey

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.


I feel like I'm misinterpreting something here. If 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 add async and await Task.Yield() in the beginning and magically, it will be async? That would pretty much be like wrapping all sync code into Task.Run() and create a fake async method.
@Krumelur There's a big difference - look at my example. If you use a Task.Run to implement it, ExecuteFooOnUIThread will run on the thread pool, not the UI thread. With await 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.
One more question: if 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?
@Krumelur Yes, it would. Just not immediately - it'd happen at a later time.
Although this answer is technically correct, the statement that "the rest of the code will execute at a later time" is too abstract and may be misleading. Execution schedule of the code after Task.Yield() is very much dependent on concrete SynchronisationContext. And MSDN documentation clearly states that "The synchronization context that is present on a UI thread in most UI environments will often prioritize work posted to the context higher than input and rendering work. For this reason, do not rely on await Task.Yield(); to keep a UI responsive."
n
noseratio

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?


In your example, what's the difference between what's there and var dialogTask = await showAsync();?
@ErikPhilips, 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.
Does await Task.Yield() have the same effect as await Task.Delay(1)?
@DavidKlempfner, yep in this case it should behave the same, but why would you pick await Task.Delay(1) over await Task.Yield()?
J
Joakim M. H.

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();
    }

This might prevent a stack overflow, but this will eventually run out of system memory if you let it run long enough. Each iteration would create a new Task that never completes, as the outer Task is awaiting an inner Task, which is awaiting yet another inner Task, and so on. This is not OK. Alternatively, you could simply have one outermost Task that never completes, and just have it loop instead of recurse. The Task would never complete, but there would only be one of them. Inside the loop, it could yield or await anything you'd like.
I can't reproduce the stack overflow. It seems that the await Task.Delay(1) is enough to prevent it. (Console App, .NET Core 3.1, C# 8)
I would have thought await Task.Delay(1); and await Task.Yield(); would do almost exactly the same thing?
k
keithyip

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?


S
Stephen Kennedy

Task.Yield() may be used in mock implementations of async methods.


You should provide some details.
For this purpose, I'd rather use Task.CompletedTask - see section Task.CompletedTask in this msdn blog post for more considerations.
The problem with using Task.CompletedTask, or Task.FromResult is that you could miss bugs that only appear when the method executes asynchronous.