.Net core & SynchronizationContext & Thread.SetData

Question

From what I know, AspNetCore doesn't have SynchronizationContext .

That “re-entering” the request context involves a number of housekeeping tasks, such as setting HttpContext.Current and the current thread’s identity and culture.

So I've created a simple .Net Core Api project with an action:

    [HttpGet]
    [Route("checkVar")]
    public async Task<IActionResult> checkVar()
    {
        Thread.SetData(Thread.GetNamedDataSlot("Random"),4);
        await Task.Delay(1000);
        var res = Thread.GetData(Thread.GetNamedDataSlot("Random"));
    }

To my suruprise , res had a value of 4. I was surprised because I believe that SetData was part of the synchronization context. (which should not exist in asp.net core)

More, when I used ConfigureAwait(false) , I got null in res.

So now I'm confused. Because ConfigureAwait shouldn't have effect in asp.net core

Question:

If asp.net core doesn't have a SynchronizationContext, then why did 4 was available after await ? why does the ConfigureAwait change the result in a non-SynchronizationContext environment?

Answer 1

I was surprised because I believe that SetData was part of the synchronization context. (which should not exist in asp.net core)

No; SetData is thread-local storage (TLS). So it's tied to a specific thread. This doesn't have anything to do with synchronization contexts.

More, when I used ConfigureAwait(false) , I got null in res.

Depending on when you run this code, how busy the server is, etc., you could get null or 4 with or without ConfigureAwait(false).

If asp.net core doesn't have a SynchronizationContext, then why did 4 was available after await ?

It's a thread-specific value. There's no SynchronizationContext on ASP.NET Core, and your code will resume on any available thread pool thread. If that thread happens to be the same thread that started that method, then the TLS is going to still be there because it's for that specific thread.

The same behavior actually applies to ASP.NET pre-Core. In that case, there is a SynchronizationContext, but that context isn't tied to any particular thread. Just like ASP.NET Core, asynchronous methods on ASP.NET pre-Core can resume on any available thread pool thread, so TLS data may or may not be there after an await.

To support this theory with data, try logging Environment.CurrentManagedThreadId before and after the await and see if there's any correlation between the data being present and the id remaining the same.