I have a method which does a long action using an async task
Now, I want to add a cache mechanism that will be transparent in the same method.
Now, I could always fetch my cache result and wrap it with a Task so it will "work" but I want to prevent the context switch that I will get.
Here's an example of what I have:
var result = await LongTask();
private async Task<string> LongTask()
{
return await DoSomethingLong();
}
And here's an example of what I want:
var result = await LongTask();
private async Task<string> LongTask()
{
if(isInCache)
{
return cachedValue(); // cache value is a const string you can do return "1" instead.
}
// else do the long thing and return my Task<string>
return await DoSomethingLong();
}
Now I'm surprised to see that this compiled and worked
Something tells me that I'm not doing it correctly.
Here's another similar example that I've tested:
private async Task<string> DownloadString(bool sync)
{
using (WebClient wc = new WebClient())
{
var task = wc.DownloadStringTaskAsync("http://www.nba.com");
if(sync)
return task.Result;
return await task;
}
}
And here's the code:
var res = DownloadString(true);
string str1 = await res;
var res2 = DownloadString(false);
string str2 = await res2;
From what I've read here task.Result executes the task synchronously and returns a string.
Now I see the request via Fiddler and my program get's stuck on the return task.Result line even though I see a 200 OK and I wait a long time.
Bottom Line:
Whats the best\correct way to use caching inside an async method(e.g. doing something synchronously in some cases without create a context switch overhead?
Why does my second block of code with the DownloadString get stuck?
First of all, if after a call to an async method the returned task is already completed there would be no context switch, because none is needed. So this is completely acceptable:
private async Task<string> LongTask()
{
if(isInCache)
{
return cachedValue(); // cache value is a const string you can do return "1" instead.
}
// else do the long thing and return my Task<string>
return await DoSomethingLong();
}
However, in the cases where the result is cached, the async mechanism is redundant. This overhead is mostly negligible but you can improve performance by dropping both the async and await and create a completed task using Task.FromResult:
private Task<string> LongTask()
{
if(isInCache)
{
return Task.FromResult(cachedValue());
}
// else do the long thing and return my Task<string>
return DoSomethingLong();
}
...when you write “await someObject;” the compiler will generate code that checks whether the operation represented by someObject has already completed. If it has, execution continues synchronously over the await point. If it hasn’t, the generated code will hook up a continuation delegate to the awaited object such that when the represented operation completes, that continuation delegate will be invoked
From Async/Await FAQ
Task.Result doesn't execute the task synchronously, it waits synchronously. That means that the calling thread is blocked waiting for the task to complete. When you use that in an environment with a SynchronizationContext that may lead to a deadlock since the thread is blocked and can't handle the task's completion. You shouldn't use the Result property on a task that hasn't completed yet.
Related
This question already has answers here:
Why use async and return await, when you can return Task<T> directly?
(9 answers)
How and when to use ‘async’ and ‘await’
(25 answers)
Closed 3 years ago.
I was looking at how to use async await, but I do not quite get it when we have multiple methods invoking each other. Should we always use await or should we only use await when we are actually ready to use the result?
So for example should we do it like this:
async Task<string[]> FooAsync()
{
var info = await Func1();
return info.split('.');
}
async Task<string> Func1()
{
return await Func2();
}
async Task<string> Func2()
{
return await tcpClient.ReadStringAsync();
}
Or like this:
async Task<string[]> FooAsync()
{
var info = await Func1();
return info.split('.');
}
Task<string> Func1()
{
return Func2();
}
Task<string> Func2()
{
return tcpClient.ReadStringAsync();
}
Per example 1, should we always use await in every method?
Or
Per example 2 should we only use await on the top-most method when we start using the result?
Every-time you call await it creates a lump of code to bundle up variables, captures the synchronization context (if applicable) and create a continuation into an IAsyncStateMachine.
Essentially, returning a Task without the async keyword will give you a small run-time efficiency and save you a bunch of CIL. Do note that the Async feature in .NET also has many optimizations already. Also note (and importantly) that returning a Task in a using statement will likely throw an Already Disposed Exception.
You can compare the CIL and plumbing differences here
Forwarded Task
Async Method
So if your method is just forwarding a Task and not wanting anything from it, you could easily just drop the async keyword and return the Task directly.
More-so, there are times when we do more than just forwarding and there is branching involved. This is where, Task.FromResult and Task.CompletedTask come into play to help deal with the logic of what may arise in a method. I.e If you want to give a result (there and then), or return a Task that is completed (respectively).
Lastly, the Async and Await Pattern has subtle differences when dealing with Exceptions. If you are returning a Task, you can use Task.FromException<T> to pop any exception on the the returned Task like an async method would normally do.
Nonsensical example
public Task<int> DoSomethingAsync(int someValue)
{
try
{
if (someValue == 1)
return Task.FromResult(3); // Return a completed task
return MyAsyncMethod(); // Return a task
}
catch (Exception e)
{
return Task.FromException<int>(e); // Place exception on the task
}
}
In short, if you don't quite understand what is going on, just await it; the overhead will be minimal. However, if you understand the subtitles of how to return a task result, a completed task, placing an exception on a task, or just forwarding. You can save your self some CIL and give your code a small performance gain by dropping the async keyword returning a task directly and bypassing the IAsyncStateMachine.
At about this time, I would look up the Stack Overflow user and author Stephen Cleary, and Mr. Parallel Stephen Toub. They have a plethora of blogs and books dedicated solely to the Async and Await Pattern, all the pitfalls, coding etiquette and lots more information you will surely find interesting.
Both options are legit and each option has own scenarios where it is more effective then another.
Of course always use await when you want to handle result of the asynchronous method or handle possible exception in current method
public async Task Execute()
{
try
{
await RunAsync();
}
catch (Exception ex)
{
// Handle thrown exception
}
}
If you don't use result of asynchronous method in current method - return the Task. This approach will delay state machine creation to the caller or where ever final task will be awaited. As pointed in the comments can make execution little bit more effective.
But there are scenarios where you must await for the task, even you do nothing with result and don't want handle possible exceptions
public Task<Entity> GetEntity(int id)
{
using (var context = _contextFactory.Create())
{
return context.Entities.FindAsync(id);
}
}
In the scenario above, FindAsync can return not completed task and this task will be returned straight away to the caller and dispose context object created within using statement.
Later when caller will "await" for the task exception will be thrown because it will try to use already disposed object(context).
public async Task<Entity> GetEntity(int id)
{
using (var context = _contextFactory.Create())
{
return await context.Entities.FindAsync(id);
}
}
And traditionally answers about Async Await must include link to Stephen Cleary's blog
Eliding Async and Await
Await is a sequencing feature which allows the caller to receive the result of an async method and do something with it. If you do not need to process the result of an async function, you do not have to await it.
In your example Func1() and Func2() do no process the return values of the called async functions, so it is fine not to await them.
When you use await the code will wait for the async function to finish. This should be done when you need a value from an async function, like this case:
int salary = await CalculateSalary();
...
async Task<int> CalculateSalary()
{
//Start high cpu usage task
...
//End high cpu usage task
return salary;
}
If you hadn't use the the await this would happen:
int salary = CalculateSalary().Result;
...
async Task<int> CalculateSalary()
{
//Start high cpu usage task
... //In some line of code the function finishes returning null because we didn't wait the function to finish
return salary; //This never runs
}
Await means, wait this async function to finish.
Use it to your needs, your case 1 and 2 would produce the same result, as long as you await when you assign the info value the code will be safe.
Source: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/index
I believe the 2nd one will do because await is expecting a return value.
Since it is waiting for the Func1() to return a value, Func1() is already executing Func2() which is returning a value.
I try to not create redundant Task objects in my code and I write Task returning functions instead of async Task functions where it is possible.
When it is necessary to save value returned by an async function, I am forced to make the function return async Task and call function with await.
Example:
async Task SomeWorkAsync()
{
someGlobalVariable = await AnotherWorkAsync();
}
What I wrote instead:
Task SomeWorkAsync()
{
var task = AnotherWorkAsync();
someGlobalVariable = task.Result;
return task;
}
But I am afraid that it will block calling thread as synchronous code does.
await SomeWorkAsync(); //main thread block
Is there another way to rewrite the code in example without wrapping a whole function with new Task as async keyword does?
I try to not create redundant Task objects in my code and I write Task returning functions instead of async Task functions where it is possible.
That's not common nor the intended way of working with the TPL.
This is wrong:
Task SomeWorkAsync()
{
var task = AnotherWorkAsync();
someGlobalVariable = task.Result;
return task;
}
You should be using
async Task<T> SomeWorkAsync()
{
someGlobalVariable = await AnotherWorkAsync();
return someGlobalVariable;
}
Only under strict circumstances should you use .Result to get the result of a Task.
To answer your question:
Yes, calling .Result will block your thread.
See my comment on why I think it's better to use await and not to return a task: https://stackoverflow.com/a/54211382/918058
If you want to save your self a state machine, just call
public Task SomeWorkAsync()
{
...
return AnotherWorkAsync();
}
Don't call Result, just return the task through without the async keyword in the method definition
In short, you are just returning a task, that can be awaited higher up
Update
Yes this does the trick if AnotherWorkAsync is async Task but in my
case it is async Task<T>
public Task<MyAwesomeType> SomeWorkAsync()
{
...
return AnotherWorkAsync();
}
Update 2
This is still not what I mean. Class which will call SomeWorkAsync
doesn't know anything about private variable someGlobalVariable. It is
necessary to get value and set this variable inside
public async Task SomeWorkAsync()
{
someGlobalVariable = await AnotherWorkAsync();
}
If you need the result from the async method you will have to await it.
Try not to mix synchronous code and the async await pattern, which you are doing with Result, you can cause deadlocks... just let async propagate
Is the following the correct way to make a async method, where the code in the method have to do multiple async calls that needs to be waited on.
The plan is to start multiple of this method, and when wait for all of them to finish before the code continues.
public static Task<string> Get(string url)
{
return Task.Run(async () =>
{
var client = getBaseHttpClient();
var result = await client.GetAsync(url).ConfigureAwait(false);
if (result.IsSuccessStatusCode)
{
return await result.Content.ReadAsStringAsync();
}
return null;
});
}
Your code:
starts a threadpool thread (Task.Run),
which will start an async I/O operation (GetAsync), and then go back to the threadpool.
When the I/O is done (await), another threadpool thread will be started (ConfigureAwait(false)),
which will start another async I/O operation to read the content of the HTTP response (GetAsStringAsync), and go back to the threadpool.
When the I/O is done (await), another threadpool thread will be started to return the content to the calling method.
You could skip step 1. altogether. All it does is defer the call to getBaseHttpClient to a threadpool thread, which I'll assume is not intensive CPU-bound work - in which case, it could/should be done synchronously.
public static async Task<string> Get(string url)
{
var client = getBaseHttpClient();
var result = await client.GetAsync(url).ConfigureAwait(false);
if (result.IsSuccessStatusCode)
{
return await result.Content.ReadAsStringAsync();
}
return null;
}
Calling code would be:
var tasks = urls.Select(Get);
var responses = await Task.WhenAll(tasks);
Why the tasks are executed before Task.WhenAll??
If you see here, from the below code snippet, first Console.WriteLine("This should be written first.."); should be printed because I am awaiting the tasks beneath to it..
But if you see the output result, the Tasks method result is being printed before the above statement. Ideally, the tasks method should be executed when I await them, but it seems that- the tasks methods are executed the moment I add them in tasks list. Why is it so?
Would you please do let me know why is this happening??
Code:
public static async Task Test()
{
var tasks = new List<Task>();
tasks.Add(PrintNumber(1));
tasks.Add(PrintNumber(2));
tasks.Add(PrintNumber(3));
Console.WriteLine("This should be written first..");
// This should be printed last..
await Task.WhenAll(tasks);
}
public static async Task PrintNumber(int number)
{
await Task.FromResult(0);
Console.WriteLine(number);
}
Output
When you call an async method you get a "hot" task in return. That means that the task already started running (and maybe even completed) before you get to await them. That means that it's quite possible for the tasks to run and complete before the call to Task.WhenAll.
In your case however, while the PrintNumber is marked async it isn't asynchronous at all since you're using Task.FromResult. The synchronous part of an asynchronous method (which is the part until you await an asynchronous task) is always executed synchronously on the calling thread and is done before the call returns. When you use Task.FromResult you get a completed task so all your method is just the synchronous part and is completed before the call returns.
When you await a completed task (as is created by Task.FromResult, it completes synchronously. This means that in your example, nothing is actually happening asynchronously, which explains the order of execution.
If instead, you were to
await Task.Yield();
you'd see output more in line with your expectations.
Task.FromResult won't cause yield and the task will be executed on the same thread. To achieve what you want you can do this:
public static async Task Test()
{
var tasks = new List<Task>();
tasks.Add(PrintNumber(1));
tasks.Add(PrintNumber(2));
tasks.Add(PrintNumber(3));
Console.WriteLine("This should be written first..");
// This should be printed last..
await Task.WhenAll(tasks);
}
public static async Task PrintNumber(int number)
{
await Task.Yield();
Console.WriteLine(number);
}
If you want a Task or tasks to run after something else, its easiest to write your code accordingly.
public static async Task Test()
{
Console.WriteLine("This should be written first..");
// These should be printed last..
await Task.WhenAll(new[]
{
PrintNumber(1),
PrintNumber(2),
PrintNumber(3)
});
}
following on from your comment.
So we have some functions,
async Task<Customer> GetRawCustomer()
{
...
}
async Task<string> GetCity(Customer customer)
{
...
}
async Task<string> GetZipCode(Customer customer)
{
...
}
We could use them like this
var rawCustomer = await GetRawCustomer();
var populationWork = new List<Task>();
Task<string> getCity;
if (string.IsNullOrWhiteSpace(rawCustomer.City))
{
getCity = GetCity(rawCustomer);
populationWork.Add(getCity);
}
Task<string> getZipCode;
if (string.IsNullOrWhiteSpace(rawCustomer.City))
{
getZipCode = GetZipCode(rawCustomer);
populationWork.Add(getZipCode);
}
...
await Task.WhenAll(populationWork);
if (getCity != null)
rawCustomer.City = getCity.Result;
if (getZipCode != null)
rawCustomer.ZipCode = getZipCode.Result;
I've read here that :
Await examines that awaitable to see if it has already completed; if
the awaitable has already completed, then the method just continues
running (synchronously, just like a regular method).
What ?
Of course it won't be completed because it hasn't even started !
example :
public async Task DoSomethingAsync()
{
await DoSomething();
}
Here await examines the awaitable to see if it has already completed
(according to the article) , but it (DoSomething) haven't event started yet ! , so the result will always be false
It would make sence if the article was to say :
Await examines that awaitable to see if it has already completed
within x ms; (timeout)
I probably missing something here..
Consider this example:
public async Task<UserProfile> GetProfileAsync(Guid userId)
{
// First check the cache
UserProfile cached;
if (profileCache.TryGetValue(userId, out cached))
{
return cached;
}
// Nope, we'll have to ask a web service to load it...
UserProfile profile = await webService.FetchProfileAsync(userId);
profileCache[userId] = profile;
return profile;
}
Now imagine calling that within another async method:
public async Task<...> DoSomething(Guid userId)
{
// First get the profile...
UserProfile profile = await GetProfileAsync(userId);
// Now do something more useful with it...
}
It's entirely possible that the task returned by GetProfileAsync will already have completed by the time the method returns - because of the cache. Or you could be awaiting something other than the result of an async method, of course.
So no, your claim that the awaitable won't have completed by the time you await it isn't true.
There are other reasons, too. Consider this code:
public async Task<...> DoTwoThings()
{
// Start both tasks...
var firstTask = DoSomethingAsync();
var secondTask = DoSomethingElseAsync();
var firstResult = await firstTask;
var secondResult = await secondTask;
// Do something with firstResult and secondResult
}
It's possible that the second task will complete before the first one - in which case by the time you await the second task, it will have completed and you can just keep going.
await can take any Task or Task<T>, including completed tasks.
In your example, the inner DoSomething() method (that should rather be named DoSomethingAsync(), and its caller DoSomethingElseAsync()) returns a Task (or a Task<T>). That task can be a completed task fetched from somewhere else, the method is not required to start its own task.