There are lots of great async tips out there, here a random few that I've collected over the past couple of years that I haven't seen much written about.
Use Discards with
Task.Run for Fire and Forget
This is a minor bit of guidance, but one of my favourites. If you are starting a
Task in a fire-and-forget manner with
Task.Run, other readers of the code might be thinking "did they forget to
await the returned task here?".
You could make your intent explicit with a comment, but a very concise and clear way to indicate this was your intention is to use the discard feature in C# 7.0:
Of course comment if you need to clarify anything, but in this example I think it makes sense to omit the comment as it leaves less noise.
Task.Factory.StartNew was often used before
Task.Run was a thing, and
StartNew can be a bit misleading when you are dealing with async code as it represents the initial synchronous part of an async delegate, due to their being no overload that takes a
Stephen Cleary even goes as far to say it is dangerous, and has very few valid use cases, including being able to start a
LongRunning task for work that will block in order to prevent blocking on your precious thread pool threads. Bar Arnon points out this almost never mixes well with async code. In short
StartNew is rarely useful, and importantly could cause confusion.
My first tip is, where ever you see the following:
to make it more familiar to other readers of the code, you can replace it with:
If you see usages without
Unwrap(), there's a chance it's not doing what you think it's doing. Or if you are using it to start a task with custom
TaskCreationOptions, be sure it's required for your scenario. To be clear, here is a rare scenario where it would make sense:
Async & Lazy
One common place where people get caught out in migrating synchronous code to async is where they have lazy initiated properties, or singletons, and it now needs to be initialized asynchronously. A great tool in your toolbelt in the sync world to deal with this is
Lazy<T>, however how can we use this with async and Tasks?
Lazy<T> uses the setting
LazyThreadSafetyMode.ExecutionAndPublication, this means it's thread-safe, and if multiple concurrent threads try to access the value, only one triggers the creation, and the others all wait for the value to become available.
What's nice is this is kind of how
Task<T> works with regards to awaiting. If one thread creates a
Task instance that is awaited by other threads before it completes, they wait for the value to become available, without additionally executing the same work. However we need a thread-safe way to create the
Task instance, so we can combine it with
Lazy<T> like this:
I've written this verbosely to be clear, but we can reduce this by making the statement a lambda, eliding the await, and replacing the invocation of
RetrieveAccessTokenAsync with the method group like this:
Note that it's important to defer the accessing of
We could encapsulate into a type like this:
Or we could use the great vs-threading library from Microsoft (if you can get over the VisualStudio namespace), which contains lots of well polished async primitives such as
AsyncLazy<T> you would almost expect to come included with the framework and part of .NET Standard.
Also, an honorable mention goes to AsyncLazy<T> defined in
Nito.AsyncEx.Coordination by Stephen Cleary.
An alternative strategy to
AsyncLazy<T> if you don't require it to be lazy, is to eagerly assign a field or property with a task in a constructor, which is started but not awaited, like this:
Async & Lock
Another thing that trips people up when migrating their synchronous code is dealing with
lock blocks, where async code cannot go. First I say, what are you trying to achieve? If it's thread-safe initialization of a resource or singleton, then use Lazy/AsyncLazy mentioned above, your code will likely be cleaner and express your intent better.
If you do need a
lock block which contains async code, try using a
SemaphoreSlim does a bit more than
Monitor and what you need for a
lock block, but you can use it in a way that gives you the same behavior. By initializing the
SemaphoreSlim with an initial value of 1, and a maximum value of 1, we can use it to get thread-safe gated access to some region of code that guarantees exclusive execution.
What's also cool is that
SemaphoreSlim has a synchronous
Wait method in addition to
WaitAsync, so we can use it in scenarios where we need both synchronous and asynchronous access (be careful of course).
It may also be worth checking out
That's it for now, a bit of a random assortment I know.
Update: Thanks to Thomas Levesque for pointing out in the comments that
SemaphoreSlim differs from
lock because it is not reentrant. This means a lock has no issue being acquired from a thread that has already acquired it, whereas with a
SemaphoreSlim you would end up deadlocking yourself under the same scenario.
Another caveat feedback by odinserj in the comments is that on .NET Framework, a thread abort exception could leave the semaphore forever depleted, so it's not bulletproof.