Why doesn't the SynchronizationContext flow here?

Question

In my Asp.Net WebApi controller (framework version 4.6.1) I have the following code:

    [Route("async_test_2")]
    public async Task<IHttpActionResult> AsyncTest2()
    {
        TelemetryDebugWriter.IsTracingDisabled = true;
        var aspNetContext = SynchronizationContext.Current;
        SynchronizationContext.SetSynchronizationContext(new SynchronizationContext()); //set context while calling AsyncMethod
        var task = AsyncMethod();
        SynchronizationContext.SetSynchronizationContext(aspNetContext); //Restore AspNet context before awaiting
        DebugContext("Before outer await");
        await Task.WhenAll(new Task[] { task });
        DebugContext("After outer await");
        return Ok();
    }

    private async Task AsyncMethod()
    {
        DebugContext("Before inner await");
        await Task.Delay(2000);
        DebugContext("After inner await");
    }

    private void DebugContext(string location)
    {
        System.Diagnostics.Debug.WriteLine(location + "  ---  SyncContext: " + (SynchronizationContext.Current?.ToString() ?? "null") + "; ManagedThreadId: " + Thread.CurrentThread.ManagedThreadId);
    }

The debug output is:

Before inner await  ---  SyncContext: System.Threading.SynchronizationContext; ManagedThreadId: 6
Before outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 6
After inner await  ---  SyncContext: null; ManagedThreadId: 5
After outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 6

Why would the continuation 'After inner await' have a null SynchronizationContext? If I simply remove the call to SetSynchronizationContext and the call to restore it (i.e. don't modify the context, leaving the default AspNetSynchronizationContext), then the context is not null in any debug output.

Before inner await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 7
Before outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 7
After inner await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 8
After outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 8

Adding 'ConfigureAwait(false)' after the inner await will cause the context to be null in the continuation as expected.

Before inner await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 7
Before outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 7
After inner await  ---  SyncContext: null; ManagedThreadId: 7
After outer await  ---  SyncContext: System.Web.AspNetSynchronizationContext; ManagedThreadId: 8

So it works as expected when the AspNetSynchronizationContext is active, but not when a default SynchronizationContext is active. In that case, it's always null in the continuation regardless of whether ConfigureAwait(false) is called.

Answer 1

Recently, I begin to learn something about SynchronizationContext, after read .Net Framewrok source code, I find that await just capture the current SynchronizationContext and Post the remain code exectution to the context, but it does not set the SynchronizaitonContext, so you got a null.

The AspNetSynchronizationContext does some extra work to ensure that even tasks are executed in different threads, the SynchronizationContext.Current are same. You can check the ISyncContext.Enter implementaion:

 // set synchronization context for the current thread to support the async pattern
        _originalSynchronizationContext = AsyncOperationManager.SynchronizationContext;
        AspNetSynchronizationContextBase aspNetSynchronizationContext = HttpContext.SyncContext;
        AsyncOperationManager.SynchronizationContext = aspNetSynchronizationContext;

the AsyncOperationManger.SynchronizationContext is just call SynchronizationContext.SetSynchronizationContext method to set SynchronizationContext.Current

You can check out this simple implementation of SynchronizationContext to replace

new SynchronizationContext()

with

new CustomSyncContext()

CustomSyncContext:

public class CustomSyncContext : SynchronizationContext
{
    private Task lastTask = Task.FromResult<object>(null);

    private object lockObj = new object();
    public override void Post(SendOrPostCallback d, object state)
    {
        Debug.WriteLine("post back from await");
        lock (lockObj)
        {

            var newTask = lastTask.ContinueWith(_=>{
                AsyncOperationManager.SynchronizationContext = this;
                d(state);
            }, TaskScheduler.Default);
            lastTask = newTask;
        }
    }

    public override SynchronizationContext CreateCopy()
    {
        return this;
    }

}

and find out that SynchronizationContext.Current is not null any more

Answer 2

SynchronizationContext.Current is thread local. Task.Delay runs on a new thread (the myth that Tasks automagically "eliminate threads" is dangerous), therefore its SynchronizationContext is null. All threads in a thread pool get null (it's unsafe to carry a real object there - they never die, you'd need very careful cleanup code after every run or you are having unholy entanglement).

That null means that continuation records are sent to the thread pool's principal tread which serializes them (in a queue) but will not run them. He's a lazy bastard :-) who delegates everything he can. Instead he will send these continuation records back into his own thread pool when their time to run comes - and won't guarantee execution order at all (that serializing was just for his own safety and is a hot spot). So, at the time your "After inner await" debug print is running, SynchronizationContext is again null and you are in unknown thread.

You'd have to write your own SynchronizationContext derivative and manage it's instances (without locking). You could assign them to thread pool's threads but you'd have to be very careful and detect when the last continuation from a chain is finished since at that point you have to clean up. You'd essentially need your own derivative of the thread class as well.

Don't forget that threads in a thread pool live forever - the whole purpose of the thread pool is to never have to destroy and latter create new thread objects. Plus GC treats all thread objects as roots which means that whatever they touch becomes eternal as well (some people would call that leaking) unless you explicitly nullify pointers.