Make runtime async callable thunks transparent #120386

jakobbotsch · 2025-10-03T21:12:00Z

Runtime async callable thunks were using TaskAwaiter directly, but that has the normal await semantics which will either post continuations to the captured synchronization context or to the thread pool. This introduces an observable behavior change with async1 where sometimes even configured awaits will end up posting back to a captured synchronization context.

For example, consider an example like:

private static async Task Foo()
{
    SynchronizationContext.SetSynchronizationContext(new TrackingSynchronizationContext());
    await Task.Delay(1000).ConfigureAwait(false);
}

Before this change the runtime async call to Task.Delay creates a runtime async callback thunk that roughly looks like

Task DelayThunk(int time)
{
    TaskAwaiter awaiter = Task.Delay(time).GetAwaiter();
    if (!awaiter.IsCompleted)
        AsyncHelpers.UnsafeAwaitAwaiter(awaiter);
    awaiter.GetResult();
}

however, when this thunk is called we end up capturing the TrackingSynchronizationContext inside the thunk. Eventually that results in the DelayThunk continuation being posted back to that synchronization context, followed by Foo's continuation being moved back to the thread pool by the runtime async infrastructure.

This PR fixes this and makes the thunks transparent in context behavior. At the same time it also optimizes the runtime async -> async1 path to be more efficient in the suspension case: the async1 task now directly invokes the runtime async infrastructure as its continuation, instead of going through multiple layers of indirection.

I also fixed a bug where we could end up invoking the wrong variant of OnCompleted for non-unsafe notifiers if they implemented both INotifyCompletion and ICriticalNotifyCompletion.

I have also renamed ThunkTask -> RuntimeAsyncTask.

This PR is still a WIP as it does not yet handle the ValueTask continuation path.

Fix #119621 (likely...)

Runtime async callable thunks were using `TaskAwaiter` directly, but that has the normal await semantics which will either post continuations to the captured synchronization context or to the thread pool. This introduces an observable behavior change with async1 where sometimes even configured awaits will end up posting back to a captured synchronization context. For example, consider an example like: ```csharp private static async Task Foo() { SynchronizationContext.SetSynchronizationContext(new TrackingSynchronizationContext()); await Task.Delay(1000).ConfigureAwait(false); } ```csharp Before this change the runtime async call to `Task.Delay` creates a runtime async callback thunk that roughly looks like ```csharp Task DelayThunk(int time) { TaskAwaiter awaiter = Task.Delay(time).GetAwaiter(); if (!await.IsCompleted) AsyncHelpers.UnsafeAwaiterAwaiter(awaiter); awaiter.GetResult(); } ``` however, when this thunk is called we end up posting back to `TrackingSynchronizationContext`, before the continuation for `Foo` then must move its continuation back to the thread pool. This PR fixes this and makes the thunks transparent in context behavior. At the same time it also optimizes the runtime async -> async1 path to be more efficient in the suspension case: the async1 task now directly invokes the runtime async infrastructure as its continuion, instead of going through multiple layers of indirection.

jakobbotsch · 2025-10-03T21:13:36Z

src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs

+        //private class RuntimeAsyncContinuation : TaskContinuation, IThreadPoolWorkItem
+        //{
+        //    private readonly Action _act;
+        //    public RuntimeAsyncContinuation(Action act)
+        //    {
+        //        _act = act;
+        //    }
+
+        //    public void Execute() => _act();
+
+        //    internal override Delegate[]? GetDelegateContinuationsForDebugger() => [_act];
+        //    internal override void Run(Task completedTask, bool canInlineContinuationTask)
+        //    {
+        //        if (canInlineContinuationTask)
+        //        {
+        //            ref Task? currentTask = ref Task.t_currentTask;
+        //            Task? prevCurrentTask = currentTask;
+        //            try
+        //            {
+        //                if (prevCurrentTask != null)
+        //                    currentTask = null;
+
+        //                // This should call into RuntimeAsyncTask.MoveNext.
+        //                _act();
+        //            }
+        //            finally
+        //            {
+        //                if (prevCurrentTask != null)
+        //                    currentTask = prevCurrentTask;
+        //            }
+        //        }
+        //        else
+        //        {
+        //            // No stack to run RuntimeAsyncTask.MoveNext, which might
+        //            // execute arbitrary continuation code.
+        //            ThreadPool.UnsafeQueueUserWorkItemInternal(this, preferLocal: true);
+        //        }
+        //    }
+        //}
+
+        //internal struct TransparentTaskAwaiter<T> : ICriticalNotifyCompletion
+        //{
+        //    private readonly Task<T> _task;
+
+        //    internal TransparentTaskAwaiter(Task<T> task)
+        //        => _task = task;
+
+        //    public bool IsCompleted => _task.IsCompleted;
+
+        //    public T GetResult()
+        //    {
+        //        TaskAwaiter.ValidateEnd(_task);
+        //        return _task.ResultOnSuccess;
+        //    }
+
+        //    public void OnCompleted(Action continuation)
+        //    {
+        //        throw new NotSupportedException();
+        //    }
+
+        //    public void UnsafeOnCompleted(Action continuation)
+        //    {
+        //        throw new NotSupportedException();
+        //    }
+        //}
+
+        //internal struct TransparentTaskAwaiter : ICriticalNotifyCompletion
+        //{
+        //    private readonly Task _task;
+
+        //    internal TransparentTaskAwaiter(Task task)
+        //        => _task = task;
+
+        //    public bool IsCompleted => _task.IsCompleted;
+
+        //    public void GetResult()
+        //    {
+        //        TaskAwaiter.ValidateEnd(_task);
+        //    }
+
+        //    public void OnCompleted(Action continuation)
+        //    {
+        //        throw new NotSupportedException();
+        //    }
+
+        //    public void UnsafeOnCompleted(Action continuation)
+        //    {
+        //        throw new NotSupportedException();
+        //    }
+        //}


This would be the higher level implementation of this -- basically a new kind of TaskContinuation that never moves the continuation to a different SynchronizationContext. However, it results in more levels of indirection and allocations than is strictly necessary, since we can have Task call into the RuntimeAsyncTask directly as the continuation.

Another possible fix - in e96e206 if our continuation wants to tun on threadpool, we clear the context before calling OnComplete so that OnComplete itself picks a continuation that matches ConfigureAwait(false)

Adding some helpers ito Task infrastructure and calling that could be another option (since we control the Task). I think we may end up doing many changes to Task to make async1-async2 interaction more efficient. It is probably not the time to do a lot of changes like that yet, but if it helps with correctness issues, then why not.

Let me look at the fix.

jakobbotsch · 2025-10-03T21:49:05Z

src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs

+            public ICriticalNotifyCompletion? CriticalNotifier;
            public INotifyCompletion? Notifier;


If someone calls AsyncHelpers.AwaitAwaiter, then that should result in call to INotifyCompletion.OnCompleted, but today if the awaiter also implements ICriticalNotifyCompletion it will instead end up calling ICriticalNotifyCompletion.UnsafeOnCompleted. This is a fix for that.

VSadov · 2025-10-06T21:27:44Z

src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs

            public Continuation? SentinelContinuation;
+            public ICriticalNotifyCompletion? CriticalNotifier;
            public INotifyCompletion? Notifier;
+            public Task? Task;


And for ValueTask we will store the result of .AsTask ?

VSadov · 2025-10-06T22:37:45Z

I think this approach will work.

I'd like to see ValueTask support. There could be some trickiness there because of IValueTaskSource and stuff related to that.
The docs recommend using .AsTask to do anything complex with ValueTask.

I think we might want to special case "IsCompleted" scenario for valuetask - to not make a Task when none is needed, but the rest can be done via .AsTask

if (valuetask.IsCompleted)
    return valuetask.Result;

Task t = valuetask.AsTask;

< .. same code as for handling Task .. >

The most common case is ValueTask wraps a value.
Then it may wrap a Task (and AsTask for that is trivial).
Then it may wrap an IValueTaskSource, and that is more complex. Perhaps .AsTask is less likely to run into some quirk or incompatible behavior.

jakobbotsch · 2025-10-07T09:49:25Z

I think this approach will work.

I'd like to see ValueTask support. There could be some trickiness there because of IValueTaskSource and stuff related to that. The docs recommend using .AsTask to do anything complex with ValueTask.

I think we might want to special case "IsCompleted" scenario for valuetask - to not make a Task when none is needed, but the rest can be done via .AsTask
if (valuetask.IsCompleted)
    return valuetask.Result;

Task t = valuetask.AsTask;

< .. same code as for handling Task .. > 
The most common case is ValueTask wraps a value. Then it may wrap a Task (and AsTask for that is trivial). Then it may wrap an IValueTaskSource, and that is more complex. Perhaps .AsTask is less likely to run into some quirk or incompatible behavior.

We can definitely do it via AsTask, though I do worry that we defeat (some of) the purpose of the ValueTask optimization then. However I think it will be good enough for now -- optimizing that is similar in spirit to #119842, in that the Continuation being created inside the thunk already has all the necessary data. We just need to find a way to generically access it and call OnCompleted. But that would probably need another stub or generic instantiation.

jakobbotsch · 2025-10-07T12:48:08Z

src/tests/async/valuetask/valuetask.cs

+    [Fact]
+    public static void RuntimeAsyncCallableThunks()
+    {
+        RuntimeAsyncCallableThunksAsync().GetAwaiter().GetResult();
+    }


Added some tests for runtime async callable thunks for ValueTask methods, since it seemed we had no coverage under the async suite.

jakobbotsch · 2025-10-07T13:11:02Z

I implemented the ValueTask part now @VSadov. Do you mind testing this on your libraries tests PR?

github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Oct 3, 2025

dotnet-policy-service bot assigned jakobbotsch Oct 3, 2025

jakobbotsch commented Oct 3, 2025

View reviewed changes

jakobbotsch added the runtime-async label Oct 3, 2025

jakobbotsch commented Oct 3, 2025

View reviewed changes

Fix function call

bbd2cdf

VSadov reviewed Oct 6, 2025

View reviewed changes

jakobbotsch added 3 commits October 7, 2025 14:18

Support ValueTask

fc0a020

Add minimal test for the actual problem

101378d

Remove commented code

e94aee2

jakobbotsch commented Oct 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Make runtime async callable thunks transparent #120386

Make runtime async callable thunks transparent #120386

jakobbotsch commented Oct 3, 2025 •

edited

Loading

Uh oh!

jakobbotsch Oct 3, 2025

Uh oh!

VSadov Oct 6, 2025

Uh oh!

jakobbotsch Oct 3, 2025

Uh oh!

VSadov Oct 6, 2025

Uh oh!

VSadov commented Oct 6, 2025

Uh oh!

jakobbotsch commented Oct 7, 2025

Uh oh!

jakobbotsch Oct 7, 2025

Uh oh!

jakobbotsch commented Oct 7, 2025

Uh oh!

Uh oh!

		public ICriticalNotifyCompletion? CriticalNotifier;
		public INotifyCompletion? Notifier;

Make runtime async callable thunks transparent #120386

Are you sure you want to change the base?

Make runtime async callable thunks transparent #120386

Conversation

jakobbotsch commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakobbotsch Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

jakobbotsch Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov commented Oct 6, 2025

Uh oh!

jakobbotsch commented Oct 7, 2025

Uh oh!

jakobbotsch Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Oct 7, 2025

Uh oh!

Uh oh!

jakobbotsch commented Oct 3, 2025 •

edited

Loading