Menu
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 BackgroundWorker.
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 [ThreadStatic] fields.
I'm trying to change this, and start using async/await 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 ConfigureAwait(false). I know that [ThreadStatic] doesn't play nice with async/await, and I've read several answers over here suggesting to use AsyncLocal<T> instead.
Given that I'm working on a large code base, as mentioned before, I'm unable to switch to async/await everywhere in a single shot, and I must do this changes gradually. So the code that before had [ThreadStatic] will change to AsyncLocal<T>, but large portions of the code will continue using BackgroundWorker and won't hit a single async/await line of code.
Question
Will this work? I need to be able to define some kind of context flow that will work with my new async/await code, and also keep working with my old non async code which relied on [ThreadStatic] keeping every thread stuff independent from each other.
If I'm totally wrong and going down the wrong path, suggestions are very welcomed.
923
The AsyncLocal<T> class also provides optional notifications when the value associated with the current thread changes, either because it was explicitly changed by setting the Value property, or implicitly changed when the thread encountered an await or other context transition.
This type is thread-safe for all members.
If you forget to use await while calling an async function, the function starts executing. This means that await is not required for executing the function. The async function will return a promise, which you can use later.
The async keyword turns a method into an async method, which allows you to use the await keyword in its body. When the await keyword is applied, it suspends the calling method and yields control back to its caller until the awaited task is complete.
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.
125
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
