I am using Web API. I know I have to use a full async stack to get its benefits. That means the API Controller are async calls to my service and my service does async calls to my dataprovider which do async datareader for example.
I guess when I start with using async in the controller I also should do an OpenAsync() on a database connection and use only the async Non-/Query calls.
Is this true?
When I have 3 NonQueries (A) doing stuff on Table 1,2,3. When this task is finished there MUST follow 4 NonQueries (B) doing stuff on Table 1,2,3.
Can I make use of the ExecuteNonQueryAsync method for A OR do I have to fear that B will be faster executed than A which might cause inconsistent data in my case?
You don't have to use only async methods, but I recommend you mostly do when there's an async option. But make sure those operations are truly async.
If you await all your async calls than the order will be the same as if you didn't use async.
There's a difference between parallel and async. An async flow isn't necessarily a parallel one.
1) False, not necessarily
2) Doesn't apply then.
By marking your actions async the apppool thread will be released for new requests and the current request is handled by a background thread.
Related
We have an async/await method GetLoanDataAsync which calls a stored procedurre through entity framework which is being called by a sync method GetData.
GetLoanData takes a good amount of time to execute and probably that was the reason that we wrote as async/await which can be used by multiple places.
I understand that we shouldn't mix async and sync calls but let's say if we have this scenario and we are using Task.Run() to call async method GetLoanDataAsync from sync method GetData which I understand that method - GetLoanDataAsync will run on a background thread.
My question is that what if we had a sync version of async method GetLoanDataAsync and called using Task.Run() from GetData than what difference it would make in this case?
Providing more details regarding the issue-
We have ASP.NET REST Web API which return type is not a Task. This is called from angular app. This api has few methods called GetData() and where we wait for the result from GetLoanDataAsync. As per my understanding GetLoanDataAsync will be called in background thread and will be able to execute GetUserDetails(), once this finish it will give back the result from executed GetLoanDataAsync.
Code -
public List<int> GetData(int id)
{
// Calls GetLoanDataAsync
var result = Task.Run(()=> GetLoanDataAsync(id));
// calls couple other sync methods
GetUserDetails();
return result.GetAwaiter().GetResult();
}
GetLoanDataAsync().Result will result in deadlock which was the earlier issue. To fix this we are temporarily trying to use Task.Run till we make overall api as an async.
If you compare a sync vs async version, then the most obvious difference is that the sync version is tying up a thread for the duration of the DB call, which seems unnecessary if all the work is at the database. Whether this is a problem depends on your throughput.
By using Task.Run, you're allowing that operation to run in parallel with other work. This is fine, as long as you don't have any touch-points that impact thread-safety, or which depend on a single logical execution flow.
If you want to use async effectively, it is best to consider it "sticky" - i.e. if X is async, then everything that calls X (directly or indirectly) needs to be async.
I need to call an async method from MeasureOverride. This call should be synchronous because I need to return the value of the async method.
I tried about a dozen different calls from these threads:
Synchronously waiting for an async operation, and why does Wait() freeze the program here
How would I run an async Task<T> method synchronously?
They all failed, some wouldn't compile in Universal Windows Applications, some weren't synchronous, some provoked a deadlock etc..
I feel strongly against async/await because of how it contaminates the call hierarchy prototypes. At the override level I'm stuck with no async keyword and I need to call await synchronously from the blackbox. Concretely how should I go about it?
The first thing you should do is take a step back. There should be no need to call asynchronous code from within a MeasureOverride in the first place.
Asynchronous code generally implies I/O-bound operations. And a XAML UI element that needs to send a request to a remote web server, query a database, or read a file, just to know what its size is, is doing it wrong. That's a fast track to app certification rejection.
The best solution is almost certainly to move the asynchronous code out of the element itself. Only create/modify the UI elements after the necessary asynchronous work completes.
That said, if you feel you must block the UI thread while asynchronous operations complete, I've compiled a list of every hack I know of, published in my MSDN article on brownfield asynchronous development.
Probably this question has already been made, but I never found a definitive answer. Let's say that I have a Web API 2.0 Application hosted on IIS. I think I understand that best practice (to prevent deadlocks on client) is always use async methods from the GUI event to the HttpClient calls. And this is good and it works. But what is the best practice in case I had client application that does not have a GUI (e.g. Window Service, Console Application) but only synchronous methods from which to make the call? In this case, I use the following logic:
void MySyncMethodOnMyWindowServiceApp()
{
list = GetDataAsync().Result().ToObject<List<MyClass>>();
}
async Task<Jarray> GetDataAsync()
{
list = await Client.GetAsync(<...>).ConfigureAwait(false);
return await response.Content.ReadAsAsync<JArray>().ConfigureAwait(false);
}
But unfortunately this can still cause deadlocks on client that occur at random times on random machines.
The client app stops at this point and never returns:
list = await Client.GetAsync(<...>).ConfigureAwait(false);
If it's something that can be run in the background and isn't forced to be synchronous, try wrapping the code (that calls the async method) in a Task.Run(). I'm not sure that'll solve a "deadlock" problem (if it's something out of sync, that's another issue), but if you want to benefit from async/await, if you don't have async all the way down, I'm not sure there's a benefit unless you run it in a background thread. I had a case where adding Task.Run() in a few places (in my case, from an MVC controller which I changed to be async) and calling async methods not only improved performance slightly, but it improved reliability (not sure that it was a "deadlock" but seemed like something similar) under heavier load.
You will find that using Task.Run() is regarded by some as a bad way to do it, but I really couldn't see a better way to do it in my situation, and it really did seem to be an improvement. Perhaps this is one of those things where there's the ideal way to do it vs. the way to make it work in the imperfect situation that you're in. :-)
[Updated due to requests for code]
So, as someone else posted, you should do "async all the way down". In my case, my data wasn't async, but my UI was. So, I went async down as far as I could, then I wrapped my data calls with Task.Run in such as way that it made sense. That's the trick, I think, to figure out if it makes sense that things can run in parallel, otherwise, you're just being synchronous (if you use async and immediately resolve it, forcing it to wait for the answer). I had a number of reads that I could perform in parallel.
In the above example, I think you have to async up as far as makes sense, and then at some point, determine where you can spin off a t hread and perform the operation independent of the other code. Let's say you have an operation that saves data, but you don't really need to wait for a response -- you're saving it and you're done. The only thing you might have to watch out for is not to close the program without waiting for that thread/task to finish. Where it makes sense in your code is up to you.
Syntax is pretty easy. I took existing code, changed the controller to an async returning a Task of my class that was formerly being returned.
var myTask = Task.Run(() =>
{
//...some code that can run independently.... In my case, loading data
});
// ...other code that can run at the same time as the above....
await Task.WhenAll(myTask, otherTask);
//..or...
await myTask;
//At this point, the result is available from the task
myDataValue = myTask.Result;
See MSDN for probably better examples:
https://msdn.microsoft.com/en-us/library/hh195051(v=vs.110).aspx
[Update 2, more relevant for the original question]
Let's say that your data read is an async method.
private async Task<MyClass> Read()
You can call it, save the task, and await on it when ready:
var runTask = Read();
//... do other code that can run in parallel
await runTask;
So, for this purpose, calling async code, which is what the original poster is requesting, I don't think you need Task.Run(), although I don't think you can use "await" unless you're an async method -- you'll need an alternate syntax for Wait.
The trick is that without having some code to run in parallel, there's little point in it, so thinking about multi-threading is still the point.
Using Task<T>.Result is the equivalent of Wait which will perform a synchronous block on the thread. Having async methods on the WebApi and then having all the callers synchronously blocking them effectively makes the WebApi method synchronous. Under load you will deadlock if the number of simultaneous Waits exceeds the server/app thread pool.
So remember the rule of thumb "async all the way down". You want the long running task (getting a collection of List) to be async. If the calling method must be sync you want to make that conversion from async to sync (using either Result or Wait) as close to the "ground" as possible. Keep they long running process async and have the sync portion as short as possible. That will greatly reduce the length of time that threads are blocked.
So for example you can do something like this.
void MySyncMethodOnMyWindowServiceApp()
{
List<MyClass> myClasses = GetMyClassCollectionAsync().Result;
}
Task<List<MyClass>> GetMyListCollectionAsync()
{
var data = await GetDataAsync(); // <- long running call to remote WebApi?
return data.ToObject<List<MyClass>>();
}
The key part is the long running task remains async and not blocked because await is used.
Also don't confuse the responsiveness with scalability. Both are valid reasons for async. Yes responsiveness is a reason for using async (to avoid blocking on the UI thread). You are correct this wouldn't apply to a back end service however this isn't why async is used on a WebApi. The WebApi is also a non GUI back end process. If the only advantage of async code was responsiveness of the UI layer then WebApi would be sync code from start to finish. The other reason for using async is scalability (avoiding deadlocks) and this is the reason why WebApi calls are plumbed async. Keeping the long running processes async helps IIS make more efficient use of a limited number of threads. By default there are only 12 worker threads per core. This can be raised but that isn't a magic bullet either as threads are relatively expensive (about 1MB overhead per thread). await allows you to do more with less. More concurrent long running processes on less threads before a deadlock occurs.
The problem you are having with deadlocks must stem from something else. Your use of ConfigureAwait(false) prevents deadlocks here. Solve the bug and you are fine.
See Should we switch to use async I/O by default? to which the answer is "no". You should decide on a case by case basis and choose async when the benefits outweigh the costs. It is important to understand that async IO has a productivity cost associated with it. In non-GUI scenarios only a few targeted scenarios derive any benefit at all from async IO. The benefits can be enormous, though, but only in those cases.
Here's another helpful post: https://stackoverflow.com/a/25087273/122718
I have wondered about this for a while now, all UserStore methods return a Task or a typed Task<T>, but why do they? Why not just return T?
I understand that they are Aync methods and are part of OWIN middleware, does that have something to do with it?
I also notice that some methods that return a plain old Task actually return an empty Task.
The samples of the asp.net website return Task.FromResult<object>(null) http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity.
I have also seen Task.FromResult(0), and if I return a Task with a Action:
return new Task(() =>
{
context.User.Add(new User); context.SaveChanges()
})
Then the Action inside the Task is not invoked. Why is this and what is the point of returning an empty Task? It seems to me that returning a Task is akin to a void method, is that correct?
First of all I really would recommend your read MSDN / Asynchronous Programming with Async and Await which is really helpful to get an understanding of HOW all of the async/await works (behind the curtains).
The reason why those techniques are actually used is that the UserManager implementations usually imply working against a database, which is "slow" in Computer time (great reading from Jeff Atwood on that topic: http://blog.codinghorror.com/the-infinite-space-between-words/).
For that reason the UserManager methods give you the promise to provide you with TypeX or ResultY in the future, but it will take time. In order to liberate resources while your application is waiting for the DB to answer (as an example) the waiting thread is put to sleep be returned to the ThreadPool, and that liberated capacity could be used for yet another incomming request (or whatever task that might have completed asynchronously during that time).
Edit: thank you #Neil Hibbert
According to MSDN / Asynchronous Programming documentation:
Asynchrony is essential for activities that are potentially blocking,
such as when your application accesses the web. Access to a web
resource sometimes is slow or delayed. If such an activity is blocked
within a synchronous process, the entire application must wait. In an
asynchronous process, the application can continue with other work
that doesn't depend on the web resource until the potentially blocking
task finishes.
Database call (specially in cloud environments like Microsoft Azure and others) is blocking I/O process and for this reason most of the APIs in the ASP.NET Identity system are asynchronous.
And why empty Task ? returning empty Task is a best practice in Async/Await Programming model. There are three possible return types for async methods: Task, Task<T>; and void, but the natural return types for async methods are just Task and Task<T>. When converting from synchronous to asynchronous code, any method returning a type T becomes an async method returning Task<T>, and any method returning void becomes an async method returning Task.
Async void methods have different error-handling semantics. When an
exception is thrown out of an async Task or async Task<T> method,
that exception is captured and placed on the Task object. With async
void methods, there is no Task object, so any exceptions thrown out
of an async void method will be raised directly on the
SynchronizationContext that was active when the async void method
started.
Async void methods have different composing semantics. Async methods
returning Task or Task<T> can be easily composed using await,
Task.WhenAny, Task.WhenAll and so on. Async methods returning void
don’t provide an easy way to notify the calling code that they’ve
completed. It’s easy to start several async void methods, but it’s
not easy to determine when they’ve finished. Async void methods will
notify their SynchronizationContext when they start and finish, but a
custom SynchronizationContext is a complex solution for regular
application code.
Async void methods are difficult to test. Because of the differences
in error handling and composing, it’s difficult to write unit tests
that call async void methods. The MSTest asynchronous testing support
only works for async methods returning Task or Task<T>. It’s possible
to install a SynchronizationContext that detects when all async void
methods have completed and collects any exceptions, but it’s much
easier to just make the async void methods return Task instead.
You should prefer async Task to async void. Async Task methods enable easier error-handling, composability and testability. For more information read this article: Best Practices in Asynchronous Programming
We have an asp.net application, it makes no use of async or parallel methods(except for some owin middleware).
I want to start using the async version of some methods using the async-await syntax.
I know that there is danger in mixing async and sync operations as that might cause a deadlocks.
It is not possible to rewrite the whole app in one go.
Where should I Start? is the safe way to do it to make the controllers actions async and work my way down? or the other way around?
Is there some clear warning sign(s) that I can watch for along the way like: "never have a sync method call an async method, but it's fine to have async call sync"
Where should I Start? is the safe way to do it to make the controllers actions async and work my way down? or the other way around?
I recommend starting at the "leaves" and creating "vertical partitions". That is, within a service or data access layer, identify I/O-bound operations. Then create asynchronous copies of those methods that use naturally-asynchronous APIs. Once you have those, then continue "up" your layers, creating asynchronous copies, until you can make a controller action asynchronous.
You'll end up with a fair amount of code duplication - both synchronous and asynchronous versions of the same method - but this is only temporary. Once all the other code only uses the asynchronous version of a method, the synchronous version can be removed.
You can safely mix sync and async IO. The deadlock arises from the way await automatically uses the ambient SynchronizationContext. Platform methods such as Stream.Read almost never do this.
Start with making long-running IO async. Short-running IO is more likely not to benefit.
It's completely safe to mix async and sync operations in your code. What's dangerous is using "sync over async" when you block on asynchronous operations inside synchronous ones.
As long as when you change a single operation you make sure it's async all the way you can add more async operations gradually.