I have a view model that is fetching a row of records and displaying on the Windows phone UI.. This view model method which fetches the data is doing a lot of Tasks, all marked with Await operations..
Looks like below:
async Task GetData()
{
var dataCollection = await GetSomeData();
await DoThis();
await DoThat();
}
The UI refreshes after the 'DoThis' call is invoked.
Now I just observed that if I introduce a Task.Delay in the code before other Tasks are done, the UI is refreshed immediately.. Which was my original Goal, to refresh the UI immediately after 'GetSomeData' Returns and then fire the other Tasks.
Looks like below:
async Task GetData()
{
var dataCollection = await GetSomeData();
await Task.Delay(100);
await DoThis();
await DoThat();
}
So what I understand from this, is that the UI thread gets opportunity to refresh after a call to Task.Delay is made. However without Task.Delay, if DoThis is called, some time is lost before it finds the first awaitable method in 'DoThis' so that it can return and continue with UI Refresh.
My questions are:
Have I understood it correct?
Is it safe to put this in production code?
Thanks in advance and hope I have explained clearly..
Pr
Below is Details of These methods as without those it is not clear what is going in the program.. :(
async Task<ObservableCollection<MyModel>> GetSomeData()
{
return await Task.Run(() =>
{
using (var db = new MainModelDataContext())
{
List<MyModel> temp =
db.Models.Where(Some condition)
.Take(30)
.ToList();
var returnCollection = new ObservableCollection<MyModel>(temp);
return returnCollection;
}
}
The ObservableCollection is bound to a list control on the UI Page. This method is being called by the page view model.
async Task DoThis()
{
// do some data processing and then post that to the Server
// this is the first awaitable method after the data processing
await (an HttpClientHandler).PostAsync();
}
Task DoThat() also follows the same flow as DoThis.. The data processing is also wrapped in async-await Tasks and they are just working on some class properties.
Hope I am clear.. Thanks again all
When you call Task.Delay, you return control to the UI message loop for those 100 milliseconds, and the UI message loop has the opportunity to process more messages from its queue. That's why you're experiencing the "refreshing" effect. If your GetSomeData method is truely asynchronous, your UI should remain responsive during its operation, and when it completes, it will continue to execute the next await.
If this effect doesn't happen, then that means your methods aren't really asynchronous, and its more likely that they are running a costly operation in a synchronous fashion which is blocking your UI thread.
Before putting this into production, you have to look into why you need Task.Delay to refresh your UI.
Related
In terms of performance, will these 2 methods run GetAllWidgets() and GetAllFoos() in parallel?
Is there any reason to use one over the other? There seems to be a lot happening behind the scenes with the compiler so I don't find it clear.
============= MethodA: Using multiple awaits ======================
public async Task<IHttpActionResult> MethodA()
{
var customer = new Customer();
customer.Widgets = await _widgetService.GetAllWidgets();
customer.Foos = await _fooService.GetAllFoos();
return Ok(customer);
}
=============== MethodB: Using Task.WaitAll =====================
public async Task<IHttpActionResult> MethodB()
{
var customer = new Customer();
var getAllWidgetsTask = _widgetService.GetAllWidgets();
var getAllFoosTask = _fooService.GetAllFos();
Task.WaitAll(new List[] {getAllWidgetsTask, getAllFoosTask});
customer.Widgets = getAllWidgetsTask.Result;
customer.Foos = getAllFoosTask.Result;
return Ok(customer);
}
=====================================
The first option will not execute the two operations concurrently. It will execute the first and await its completion, and only then the second.
The second option will execute both concurrently but will wait for them synchronously (i.e. while blocking a thread).
You shouldn't use both options since the first completes slower than the second and the second blocks a thread without need.
You should wait for both operations asynchronously with Task.WhenAll:
public async Task<IHttpActionResult> MethodB()
{
var customer = new Customer();
var getAllWidgetsTask = _widgetService.GetAllWidgets();
var getAllFoosTask = _fooService.GetAllFos();
await Task.WhenAll(getAllWidgetsTask, getAllFoosTask);
customer.Widgets = await getAllWidgetsTask;
customer.Foos = await getAllFoosTask;
return Ok(customer);
}
Note that after Task.WhenAll completed both tasks already completed so awaiting them completes immediately.
Short answer: No.
Task.WaitAll is blocking, await returns the task as soon as it is encountered and registers the remaining part of the function and continuation.
The "bulk" waiting method you were looking for is Task.WhenAll that actually creates a new Task that finishes when all tasks that were handed to the function are done.
Like so: await Task.WhenAll({getAllWidgetsTask, getAllFoosTask});
That is for the blocking matter.
Also your first function does not execute both functions parallel. To get this working with await you'd have to write something like this:
var widgetsTask = _widgetService.GetAllWidgets();
var foosTask = _fooService.GetAllWidgets();
customer.Widgets = await widgetsTask;
customer.Foos = await foosTask;
This will make the first example to act very similar to the Task.WhenAll method.
As an addition to what #i3arnon said. You will see that when you use await you are forced to have to declare the enclosing method as async, but with waitAll you don't. That should tell you that there is more to it than what the main answer says. Here it is:
WaitAll will block until the given tasks finish, it does not pass control back to the caller while those tasks are running. Also as mentioned, the tasks are run asynchronous to themselves, not to the caller.
Await will not block the caller thread, it will however suspend the execution of the code below it, but while the task is running, control is returned back to the caller. For the fact that control is returned back to the caller (the called method is running async), you have to mark the method as async.
Hopefully the difference is clear. Cheers
Only your second option will run them in parallel. Your first will wait on each call in sequence.
As soon as you invoke the async method it will start executing. Whether it will execute on the current thread (and thus run synchronously) or it will run async is not possible to determine.
Thus, in your first example the first method will start doing work, but then you artificially stops the flow of the code with the await. And thus the second method will not be invoked before the first is done executing.
The second example invokes both methods without stopping the flow with an await. Thus they will potentially run in parallel if the methods are asynchronous.
I have a method in my view model
private async void SyncData(SyncMessage syncMessage)
{
if (syncMessage.State == SyncState.SyncContacts)
{
this.SyncContacts();
}
}
private async Task SyncContacts()
{
foreach(var contact in this.AllContacts)
{
// do synchronous data analysis
}
// ...
// AddContacts is an async method
CloudInstance.AddContacts(contactsToUpload);
}
When I call SyncData from the UI commands and I'm syncing a large chunk of data UI freezes. But when I call SyncContacts with this approach
private void SyncData(SyncMessage syncMessage)
{
if (syncMessage.State == SyncState.SyncContacts)
{
Task.Run(() => this.SyncContacts());
}
}
Everything is fine. Should not they be the same?
I was thinking that not using await for calling an async method creates a new thread.
Should not they be the same? I was thinking that not using await for
calling an async method creates a new thread.
No, async does not magically allocate a new thread for it's method invocation. async-await is mainly about taking advantage of naturally asynchronous APIs, such as a network call to a database or a remote web-service.
When you use Task.Run, you explicitly use a thread-pool thread to execute your delegate. If you mark a method with the async keyword, but don't await anything internally, it will execute synchronously.
I'm not sure what your SyncContacts() method actually does (since you haven't provided it's implementation), but marking it async by itself will gain you nothing.
Edit:
Now that you've added the implementation, i see two things:
I'm not sure how CPU intensive is your synchronous data analysis, but it may be enough for the UI to get unresponsive.
You're not awaiting your asynchronous operation. It needs to look like this:
private async Task SyncDataAsync(SyncMessage syncMessage)
{
if (syncMessage.State == SyncState.SyncContacts)
{
await this.SyncContactsAsync();
}
}
private Task SyncContactsAsync()
{
foreach(var contact in this.AllContacts)
{
// do synchronous data analysis
}
// ...
// AddContacts is an async method
return CloudInstance.AddContactsAsync(contactsToUpload);
}
What your line Task.Run(() => this.SyncContacts()); really does is creating a new task starting it and returning it to the caller (which is not used for any further purposes in your case). That's the reason why it will do its work in the background and the UI will keep working. If you need to (a)wait for the task to complete, you could use await Task.Run(() => this.SyncContacts());. If you just want to ensure that SyncContacts has finished when you return your SyncData method, you could using the returning task and awaiting it at the end of your SyncData method. As it has been suggested in the comments: If you're not interested in whether the task has finished or not you just can return it.
However, Microsoft recommend to don't mix blocking code and async code and that async methods end with Async (https://msdn.microsoft.com/en-us/magazine/jj991977.aspx). Therefore, you should consider renaming your methods and don't mark methods with async, when you don't use the await keyword.
Just to clarify why the UI freezes - the work done in the tight foreach loop is likely CPU-bound and will block the original caller's thread until the loop completes.
So, irrespective of whether the Task returned from SyncContacts is awaited or not, the CPU bound work prior to calling AddContactsAsync will still occur synchronously on, and block, the caller's thread.
private Task SyncContacts()
{
foreach(var contact in this.AllContacts)
{
// ** CPU intensive work here.
}
// Will return immediately with a Task which will complete asynchronously
return CloudInstance.AddContactsAsync(contactsToUpload);
}
(Re : No why async / return await on SyncContacts- see Yuval's point - making the method async and awaiting the result would have been wasteful in this instance)
For a WPF project, it should be OK to use Task.Run to do the CPU bound work off the calling thread (but not so for MVC or WebAPI Asp.Net projects).
Also, assuming the contactsToUpload mapping work is thread-safe, and that your app has full usage of the user's resources, you could also consider parallelizing the mapping to reduce overall execution time:
var contactsToUpload = this.AllContacts
.AsParallel()
.Select(contact => MapToUploadContact(contact));
// or simpler, .Select(MapToUploadContact);
I'm creating my own UI handling logic that runs on a single thread. Basically, what I'm doing is
void HandlerMain()
{
while (true)
{
Task[] events = PumpEvents();
Task.WaitAll(events);
}
}
where one example task that PumpEvents() returns is
async Task ButtonClick()
{
var httpClient = new HttpClient();
string s = await httpClient.GetStringAsync("http://microsoft.com");
Console.WriteLine(s);
}
The problem of my code is, if one of events takes a long time, it's stuck at Task.WaitAll(), so it can't pump new events making the UI not responsive. Is there any other method than WaitAll() something like
Task[] remainingEvents = PumpEvents();
while (true)
{
remainingEvents = WaitUntilEveryTasksAwait(remainingEvents);
remainingEvents.Append(PumpEvents());
}
Maybe I'm on wrong track. I'd appreciate your advice!
#ScottChamberlain No. The built-in UI processor, say WPF, correctly handles async events so whenever the async events do "await", it skips the current context and handles the next events. I want to duplicate this behavior
Based on your comment to me I now understand what your problem is. You need more logic than your simple while(true) loop to be able to process the await messages. The entire system is built up upon the class SynchronizationContext, what you will need to do is derive your own class from SynchronizationContext and override it's methods to queue up your work to be done inside your while loop.
See this article from Stephen Cleary to give you more information on how a Synchronization Context works and posibly some ideas on where to start writing your own.
If I'm understanding, you don't actually need to wait until those tasks are complete to continue. Just remove the call to Task.WaitAll.
For the record, Task.WaitAll is synchronous -- it blocks. You're better off using Task.WhenAll, which returns a task that completes when all of the provided tasks are complete. That lets you await it just like you'd await any of the individual tasks. Just doing that would solve the problem and keep the UI responsive.
E.g.:
async Task HandlerMain()
{
while (true)
{
Task[] events = PumpEvents();
await Task.WhenAll(events);
}
}
Of course, in this case, depending on what was calling HandlerMain, you'd still have the problem where PumpEvents was hung up waiting on the long-running task.
This starts to lead down the path of questions like, "Why are you writing your own custom UI message pump when WPF and WinForms have that problem already solved?"
I have a WPF form with several tabs on in. When I load the form I am also trying to load some data in the background for some of the tabs.
The code looks like this:
public static List<MyModel> GetCaseNotes(int someId)
{
return GetCaseNotesAsync(debtorId).Result;
}
public static async Task<List<MyModel>> GetCaseNotesAsync(int someId)
{
Task<List<MyModel>> tsk = Task.Run(() => GetCaseNotesFromDb(someId));
return await tsk.ConfigureAwait(false);
}
public static List<MyModel> GetCaseNotesFromDb(int debtorId)
{
//get some data from database
}
However, the UI is still waiting for the data to be taken from database... Any ideas?
Result will block until the task completes. You've avoided the deadlock I describe on my blog by using ConfigureAwait, but you're still explicitly blocking.
When loading data asynchronously, you'll need to design in a "loading" state for your UI and update it when the loading completes. I have another blog entry on asynchronous construction/initialization that you may find useful, in particular my NotifyTaskCompletion type attempts to make tasks more data-binding-friendly.
return GetCaseNotesAsync(debtorId).Result;
should be
return await GetCaseNotesAsync(debtorId);
When you call Result on a Task, you wait synchronously for the result, not asynchronously.
Because you have async method but calling it synchronously. Calling Async method without await will cause it to behave as a synchronous method.
In order to call it asynchronously you should call it like this
return await GetCaseNotesAsync(debtorId);
I have this:
BusyState.SetBusy("Updating Calendar Data");
Dispatcher.CurrentDispatcher.Invoke(new Action(async () =>
{
// calling "update" will hit servers outside my control and may take time
await PublicCalendars.Update();
await PrivateCalendars.Update();
// clearing the busy state should only happen when both update tasks are finished
BusyState.ClearBusy();
}));
The vars PublicCalendars and PrivateCalendars are both extending ObservableCollection and are populated during the call to update. The collections are bound to some WPF GUI so adding items must happen from the UI thread.
I'd like to remove the await's and let both calls run simultaneously. How can I do this and still have my busy state clear when both tasks are finished?
The strength of Tasks is that they can be easily composed. So, if you want to get a Task that represents the completion of both Tasks, you can use a method that does that: Task.WhenAll():
await Task.WhenAny(PublicCalendars.Update(), PrivateCalendars.Update());
BusyState.ClearBusy();
And you could also get a very similar behavior by yourself by saving the returned Tasks and then awaiting them:
var publicTask = PublicCalendars.Update();
var privateTask = PrivateCalendars.Update();
await publicTask;
await privateTask;
BusyState.ClearBusy();