Proposal: 'Yield()' APIs for 'TaskScheduler' and 'SynchronizationContext' for easy, efficient context switching in GUI apps

[Sergio0694]

Note

Opening a discussion first as suggested by @tannergooding, so we can refine the proposal (eg. the exact API name) better before moving to an issue. The idea is to avoid having a discussion that drags too much just because of secondary details in an issue.

Background and motivation

In GUI apps, it's extremely common to have to switch back and forth between different threads. The main reasons are usually that (1) most UI elements are tied to the UI thread, and will throw exceptions if accessed from anywhere else, and (2) in order to avoid stutters and dropping frames, it is very common to move work off the UI thread as much as possible, and then move back to the UI thread to signal results to the UI (eg. to update properties that are bound to the UI).

There currently is no built-in, convenient way to do these two operations. It is an extremely common pain point, and developers usually end up building the same kind of helpers for this over and over again. It also often comes up as a discussion point in C# components in Windows, where we're adopting C# in areas where before we would've used C++ (which does offer helpers for this kind of scenarios, in C++/WinRT, namely resume_foreground and resume_background). Projects like Visual Studio also have equivalent helpers.

Prior art

Generally speaking, there's multiple common solutions for this:

1. Using callbacks:

// Work on current thread

_ = Task.Run(() =>
{
    // Work on thread pool

    _ = _dispatcherQueue.TryEnqueue(() =>
    {
        // Work on UI thread
    });
});

• Pros: no need for additional helpers
• Cons: absolutely horrible to read and maintain, very inefficient, leaks UI references to backend code

1. Using custom services (eg. Microsoft Store, Visual Studio)

// Work on current thread

await dte.Current.JoinableTaskFactory.SwitchToThreadPoolAsync();

// Work on thread pool

await dte.Current.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken);

// Work on UI thread

• Pros: nice inline code flow, efficient lowering (shared async state machine for all continuations and locals)
• Cons: need to implement all this yourself, need to inject services everywhere, not self-contained

Proposal

The proposal is for two awaiters that handle switching to their associated context, something like:

namespace System.Threading.Tasks
{
    public static class TaskSchedulerExtensions
    {
        public static TaskSchedulerYieldAwaiter Yield(this TaskScheduler taskScheduler);
    }
}

namespace System.Threading
{
    public static class SynchronizationContextExtensions
    {
        public static SynchronizationContextYieldAwaiter Yield(this SynchronizationContext synchronizationContext);
    }
}

Both would return an awaitable that:

• Runs the continuation inline if already on that scheduler/context
• Queues the continuation there otherwise

Examples

The previous example would just become this:

// Work on current thread

await TaskScheduler.Default.Yield();

// Work on thread pool

await _synchronizationContext.Yield();

// Work on UI thread

Where _synchronizationContext is just SynchronizationContext.Current, which eg. viewmodels can get in the constructor.

cc. @tannergooding @stephentoub could you share your thoughts? I'd like to refine this API shape and make it into an actual proposal, which I'd hope to get into .NET 10. The topic keeps coming up, especially as we adopt C# in more places in Windows 😄

Thank you!

[huoyaoyuan]

This should integrate seamlessly with multiple UI threads, right? In UWP each AppView has a separated UI thread.

[Sergio0694]

This would do that, because it'd just capture whatever synchronization context is set for a given thread. So eg. you'd just get the context when constructing the view model, which is retriever from each specific view, and things would just work 🙂

[huoyaoyuan]

I used to share leaf view models among multiple AppViews. It was really an unpleasant experience. Ultimately the problem becomes dispatching data updates to multiple UI threads, which is out of scope of this proposal.

[Sergio0694]

Yeah that would be a different scenario and it's not something that's even supported by virtually any UI framework out there anyway. There's no way to have a shared viewmodel with properties bound to UI element that way anyway, because that'd just crash on all other views except the one bound to the context that happened to raise the notification 😅

So yeah, I'd say that's outside the scope here.

[stephentoub]

#20025

[murshex]

I support these changes