I came across some best practices for asynchronous programming using c#'s async
/await
keywords (I'm new to c# 5.0).
One of the advices given was the following:
Stability: Know your synchronization contexts
... Some synchronization contexts are non-reentrant and single-threaded. This means only one unit of work can be executed in the context at a given time. An example of this is the Windows UI thread or the ASP.NET request context. In these single-threaded synchronization contexts, it’s easy to deadlock yourself. If you spawn off a task from a single-threaded context, then wait for that task in the context, your waiting code may be blocking the background task.
public ActionResult ActionAsync() { // DEADLOCK: this blocks on the async task var data = GetDataAsync().Result; return View(data); } private async Task<string> GetDataAsync() { // a very simple async method var result = await MyWebService.GetDataAsync(); return result.ToString(); }
If I try to dissect it myself, the main thread spawns to a new one in MyWebService.GetDataAsync();
, but since the main thread awaits there, it waits on the result in GetDataAsync().Result
. Meanwhile, say the data is ready. Why doesn't the main thread continue it's continuation logic and returns a string result from GetDataAsync()
?
Can someone please explain me why there is a deadlock in the above example? I'm completely clueless about what the problem is ...
The deadlock explained. The “async” and “await” keywords do not create any additional threads. Async methods are intended to be non-blocking operations. The method runs on the current “synchronization context” and uses time on the thread only when the method is active. You should use “Task.
Deadlock occurs when a resource is locked by a thread and is required by another thread at the same time. This problem occur frequenty in a multiprocessing system. Thread One will not get Lock Q since it belongs to Thread Two.
The await operator doesn't block the thread that evaluates the async method. When the await operator suspends the enclosing async method, the control returns to the caller of the method.
Take a look at this example, Stephen has a clear answer for you:
So this is what happens, starting with the top-level method (
Button1_Click
for UI /MyController.Get
for ASP.NET):
The top-level method calls
GetJsonAsync
(within the UI/ASP.NET context).
GetJsonAsync
starts the REST request by callingHttpClient.GetStringAsync
(still within the context).
GetStringAsync
returns an uncompletedTask
, indicating the REST request is not complete.
GetJsonAsync
awaits theTask
returned byGetStringAsync
. The context is captured and will be used to continue running theGetJsonAsync
method later.GetJsonAsync
returns an uncompletedTask
, indicating that theGetJsonAsync
method is not complete.The top-level method synchronously blocks on the
Task
returned byGetJsonAsync
. This blocks the context thread.... Eventually, the REST request will complete. This completes the
Task
that was returned byGetStringAsync
.The continuation for
GetJsonAsync
is now ready to run, and it waits for the context to be available so it can execute in the context.Deadlock. The top-level method is blocking the context thread, waiting for
GetJsonAsync
to complete, andGetJsonAsync
is waiting for the context to be free so it can complete. For the UI example, the "context" is the UI context; for the ASP.NET example, the "context" is the ASP.NET request context. This type of deadlock can be caused for either "context".
Another link you should read: Await, and UI, and deadlocks! Oh my!
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