Fede Fede -4 years ago 173
C# Question

What's the effect of AsyncLocal<T> in non async/await code?

I'm working on a very large and old code base of a desktop winform application. In this code base there are lots of operations performed in background threads, mainly using


A common pattern in this code base, is to hide complexity by binding artifacts to the thread being executed. For instance, the database connection and transaction are stored in

I'm trying to change this, and start using
code, and benefit from running the task in any thread of the pool, and allowing a task to continue executing in any other thread by using
. I know that
doesn't play nice with
, and I've read several answers over here suggesting to use

Given that I'm working on a large code base, as mentioned before, I'm unable to switch to
everywhere in a single shot, and I must do this changes gradually. So the code that before had
will change to
, but large portions of the code will continue using
and won't hit a single
line of code.


Will this work? I need to be able to define some kind of context flow that will work with my new
code, and also keep working with my old non async code which relied on
keeping every thread stuff independent from each other.

If I'm totally wrong and going down the wrong path, suggestions are very welcomed.

Answer Source

It should work.

AsyncLocal<T> is an abstraction of the logical call context. I describe the logical call context and how it interacts with async/await in detail in an old blog post.

In summary, it will probably work fine, but there is one aspect of AsyncLocal<T> that is quite different than ThreadStatic.

When you write to the AsyncLocal<T> value, that value is set for the current logical call context. An async method will establish a copy-on-write scope for its logical call context, so if you write to it within an async method, it will create a new logical call context that contains the new value. This allows async method to use it in a nested fashion, where "inner" contexts can overwrite "outer" contexts. However, the "inner" context values never flow back to the caller; when the "outer" context is resumed, it completely replaces the "inner" context.

If none of the methods are async and the values are only set from their own threads, then that thread just has a single logical call context, and writing/reading the values will work just the same as ThreadStatic.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download