Will await Task.Yield() be optimized away?

[CeSun]

I am trying to do this on winform and maui framework:

private async void button1_Click(object sender, EventArgs e)
{
    while(true)
    {
        await Task.Yield();
    }
}

My expectation is that the interface will not become unresponsive, but the result is the opposite of what I thought, the interface is unresponsive anymore.

But my friend has no problem on Xamarin for Android, as expected.
I suspect that Yield is optimized away.

[CeSun]

await Task.Delay(0) has the same problem. Before knowing the Yield function, I tried using Delay(0) to achieve the same effect, but it seems to be optimized away.

[CeSun]

maui runs fine on android.

private async void OnCounterClicked(object sender, EventArgs e)
{
      for(int i = 0; i < int.MaxValue; i ++)
      {
          Count++;
	await Task.Yield();
      }
}

<Button 
                x:Name="CounterBtn"
                Text="{Binding Count}"
                SemanticProperties.Hint="Counts the number of times you click"
                Clicked="OnCounterClicked"
                HorizontalOptions="Center" />

[CarnaViire]

@Redth is it something that should be transferred to dotnet/maui?

[CeSun]

@Redth is it something that should be transferred to dotnet/maui?

I think it's not just the Maui problem, because WinForm also has problems.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I am trying to do this on winform and maui framework:

private async void button1_Click(object sender, EventArgs e)
{
    while(true)
    {
        await Task.Yield();
    }
}

My expectation is that the interface will not become unresponsive, but the result is the opposite of what I thought, the interface is unresponsive anymore.

But my friend has no problem on Xamarin for Android, as expected.
I suspect that Yield is optimized away.

Author:	CeSun
Assignees:	-
Labels:	area-System.Threading.Tasks
Milestone:	-

[Clockwork-Muse]

... having an infinite loop seems like a strange thing to do in an event handler. Why are you doing that, as opposed to something like just awaiting whatever task you've submitted? What's the underlying problem you're trying to solve?

Outside of that, the delay/yield might not be optimized out, it's just that it might be getting picked up by the UI thread again before other processing happens.

[tfenise]

I don't think Task.Yield() can be optimized away. For Winform, it is probably because WindowsFormsSynchronizationContext.Post() "posts" a message, and "posted" messages have higher priority than input messages.

In Winform, you can try System.Windows.Forms.Application.DoEvents() to keep responsive.
By the way, WPF offers System.Windows.Threading.Dispatcher.Yield(DispatcherPriority), with which a low priority could be given.

[CeSun]

... having an infinite loop seems like a strange thing to do in an event handler. Why are you doing that, as opposed to something like just awaiting whatever task you've submitted? What's the underlying problem you're trying to solve?

Outside of that, the delay/yield might not be optimized out, it's just that it might be getting picked up by the UI thread again before other processing happens.

For example, I have a large amount of data that needs to be updated to the user interface. If I update it directly, the interface may get stuck, because it is a long time and CPU intensive work. So in order to prevent the UI thread's ticks from getting stuck, I want to use the state machine mechanism of the co process to divide the long CPU intensive code into multiple segments and execute it in multiple ticks of the UI thread.

[CeSun]

I don't think Task.Yield() can be optimized away. For Winform, it is probably because WindowsFormsSynchronizationContext.Post() "posts" a message, and "posted" messages have higher priority than input messages.

In Winform, you can try System.Windows.Forms.Application.DoEvents() to keep responsive.
By the way, WPF offers System.Windows.Threading.Dispatcher.Yield(DispatcherPriority), with which a low priority could be given.

I am not sure that the input is scheduled by the synchronization context.

The simplified model I understand is as follows:

main()
{
   while(!NeedExit)
   {
      Input.Tick();
      UI.Tick();
      SyncContext.Tick(); 
   }
}

If I do not call await task.yield (), my CPU intensive code is executed in the button event, possibly in the input.Tick() is executed at one time.

If I call await task.yield(), my CPU intensive code will be split into multiple code segments and sent or post to the synchronization context, which will schedule execution.

[Clockwork-Muse]

I want to use the state machine mechanism of the co process to divide the long CPU intensive code into multiple segments and execute it in multiple ticks of the UI thread.

No you don't. And what you're currently doing isn't guaranteed to work anyways:

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.

(this was essentially what my first comment was assuming was happening, even before I started searching)

What you actually want to do is run the CPU-intensive work on another thread, so that the UI thread isn't blocked at all, probably by starting something via Task.Run(...). This blog post series goes over your two options, and how to interact back with the UI thread when appropriate

[CeSun]

I want to use the state machine mechanism of the co process to divide the long CPU intensive code into multiple segments and execute it in multiple ticks of the UI thread.

No you don't. And what you're currently doing isn't guaranteed to work anyways:

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.

(this was essentially what my first comment was assuming was happening, even before I started searching)

What you actually want to do is run the CPU-intensive work on another thread, so that the UI thread isn't blocked at all, probably by starting something via Task.Run(...). This blog post series goes over your two options, and how to interact back with the UI thread when appropriate

What should I do if my CPU intensive work is to update the UI?

For example, I have 2000 data and want to put them all on the interface.

If it is placed in another thread, it will cause an exception.

[Clockwork-Muse]

.... it seems unlikely that just adding 2000 elements would be sufficient to lock the UI for a large amount of time, but rather that whatever you're doing to gather the data is taking a large amount of time. If it's your UI code, you may need to refactor something - but what you may need to change is better handled in general coding forums. If it's the UI framework, reporting performance problems is appreciated, but we'd need a repro.

If it is placed in another thread, it will cause an exception.

You're right about this. See some of the later entries for examples.

• If updating the UI is actually fast, but gathering the data is slow, just awaiting the results should be sufficient.
• If updating the UI is for some reason slow, you'd probably best be served by creating some form of Progress<T> that you can post results (possibly batched) to. This would increase the time it takes to completely all the updates, but should keep it otherwise responsive.

In either case, your next step is figuring out which more specific part of your code is slow, then asking for more targeted advice on someplace like StackOverflow or the C# discord.

Unless you can provide a specific repro for slow UI in general, there isn't anything actionable on our end.

[tfenise]

For example, I have 2000 data and want to put them all on the interface.

How do you put them all on the interface? Typically one uses some sort of data binding, rather than creating 2000 controls for all pieces of data or putting all data directly into the content of a control.

[buyaa-n]

I don't think it is runtime/threading issue, consider @Clockwork-Muse's suggestion.

Transferring to MAUI for more suggestions on how such UI should be loaded

[hartez]

I've converted this to a discussion, since it's not a MAUI-specific issue and it's working as expected* on the currently supported MAUI platform (Android). In any case, this isn't something actionable for the MAUI team.

Hopefully someone here can help with suggestions on how to handle the specific UI challenges.

• the expectation itself may be incorrect