Related
EDIT: Updating LongTask() to be await Task.Delay(2000); makes it work how I need, so thanks for the answers, y'all!
I am trying to call an async function from within a sync function to let the sync function keep going before the async function is finished. I don't know why the code below waits for LongTask() to complete before continuing. I thought it should only do that if I did await LongTask(). Can someone help me understand what I'm missing?
C# fiddle here
using System;
using System.Diagnostics;
using System.Threading.Tasks;
public class Program
{
public static void Main()
{
var timer = new Stopwatch();
timer.Start();
LongTask();
timer.Stop();
long ms = timer.ElapsedMilliseconds;
Console.WriteLine(ms.ToString());
}
async static void LongTask()
{
Task.Delay(2000).Wait();
}
}
Here's the short short intro to async/await
You know when you're playing some God type game where you e.g. set your settlers building a load of buildings, or cutting trees/making food etc and then you have literally nothing else to do except sit and watch them finish, then you can start again, getting the buildings to churn out knights or catapults or whatever?
It's a bit of a waste of life, you sitting there doing nothing other than waiting for something to finish, then you can carry on with some other task..
As a human you probably don't do that; you go make a cup of coffee, call a friend, hit the punchbag, maybe even go play the space exploration game, set the autopilot of whatever ship to guide you to some star system on a journey that'll take 5 mintues of waiting and watching stars pass.. Autopilot set, coffee made, buildings still not finished, bored of the punchbag.. So you go clean up..
This isn't doing things in parallel; you aren't wiping the floor with a cloth while stirring the coffe and chatting on the phone, but it's making great use of your time, cracking through the todo list by pouring a load of energy into one thing, getting as far as you can, then switching to the next thing. You do one thing at once, but when you get stuck you move onto another thing. If you sat and waited for everything you'd need 10 copies of you to get 10 stop/start jobs done
async/await is the same thing. It takes syncronous code - something that is done from start to finish in one long operation that is the sole focus of your thread's attention, even if there's a 5 minute Wait() in the middle of it where it literally sits and does nothing for 5 minutes - and chops it up into a bunch of separate methods that are controlled by a process that allows the thread to pick up where it left off of
Marking a method async is the indicator to C# that the compiler is allowed to invisbly cut the method up into pieces that can be put down and picked up when needed
await is the indicator where you're saying "I've reached a point where I need some operation to finish before I can progress any further with this; go and find something else to do". When it encounters an await your thread will stop work on your code because it's being told it to do nothing more until the background operation completes (it's not important what is doing the work, lets imagine it's some background thread) and your thread will go and do something else until the result is ready. This really simplifies a lot of programming related stuff because you only ever deal with one thread - it's code that behaves like syncronous code but goes and does something else instead of doing nothing when it gets stuck
As a keyword await has to be followed by something that is awaitable, usually a Task or Task<T> - it represents the operation that is already set to happen. When the operation is finished and the thread returns await also helpfully unwraps the Task object that was controlling this process, and gives you the result..
If you take nothing else away from this, at the very least learn:
you must mark a method as async if you want to use await inside it. You should generally make the return type of an sync method as either Task (if it returns no value) or Task<X> (if it returns a value of type X). You should also call the method a name ending in ..Async
When you start some operation that works asyncronously (you call some method that is called ..Async), and you get a Task<X> object in return, use await on it to get the X you actually want
Making an async method means the method that calls it also has to be async, and the method that calls that also has to be async.. and.. All the way up the tree and out of your code. That's how your thread can "escape" when it has to go find something else to do - it needs to escape out of your code, so you make a route for that to happen by declaring "async all the way up"
I said in the comments not to use a console app. Let's imagine you have a Windows Forms app. Win Forms apps typically have one thread that does everything. One thread draws the UI, and when you click a button it comes and runs all the code you put in the button_Click() handler. While it's doing that it's not doing its normal job of drawing the UI. You can set statusLabel.Text = "Downloading data.." as the very first line of the method, and you can launch a download of a 1 gig file, and then you can set the status Label to "Finished " + downloadedFile.Length. You click the button, and you see nothing - the UI of your app jams frozen for 30 seconds while the file downloads. Then it suddenly says "Finished 1024000000" in the label:
void button_Click(object sender, EventArgs e){
statusLabel.Text = "Starting download";
string downloadedFile = new SomeHttpDownloadStringThing("http://..");
statusLabel.Text = "Finished " + downloadedFile.Length;
}
Why? Well.. the thread that draws the UI and would have painted the label pixels on the screen got really busy downloading the file. It went into that SomeHttpDownloadStringThing method and didn't come out for 30 seconds, then it came out, set the status label text again, then it left your code and went back to whatever land it normally lives in. It drew the pixels on screen "Finished..". It never even knew it had to draw "Starting download".. That data was overwritten well before it picked up its paintbrush again
Let's turn it async:
async void button_Click(object sender, EventArgs e){
statusLabel.Text = "Starting download";
string downloadedFile = await SomeHttpDownloadStringThingAsync("http://..");
statusLabel.Text = "Finished " + downloadedFile.Length;
}
SomeHttpDownloadStringThing returned a string. SomeHttpDownloadStringThingAsync returned a Task<string>. When the UI thread hits that await imagine it tells some background thread to go download the file, puts this method on pause, and returns out of it and goes back to drawing the UI. It paints the label as "Starting ..." so you see it, and then maybe finds some other stuff to do. If you had a Timer ticking up counting how long the download had been then your timer would increment nicely too - bcause the UI thread is free to do it, it's not sitting awaiting for Windows to do the download while it does nothing other than wait.
When the download finishes, the thread is called back to where it was and it picks up from there. It doesn't run the first code again, it doesn't set the status label to "Starting" again.
It literally starts from the SomeHttpDownloadStringThingAsync part as if it had never left, the await converts the Task<string> into a string of the downlaoded file, and then the UI thread can set the "Finished.." text
The whole thing is just like the syncronous version, except that little bit in the middle where the UI thread was allowed to go back to its regular job of drawing pixels on the screen and handling other user interaction
This is why I say console apps are hard work for understanding async/await because their UI doesn't obviously do anything else while an await is in progress, unless you've arranged for something to happen, but that's more work. UI apps automatically have other stuff going on, and if you jam up the threads that do that stuff, they freeze, and turn "Not responding"
If you have an eagle eye, you'll have spotted async void on the handler even though I said "if you have a void method, make it return Task when you make it async" - winforms event handlers are a bit of a special case in that regard, you cannot make them async Task but they're an exception rather than a rule. For now, rule of thumb - avoid async void
As already mentioned in the comments:
you have to use await Task.Delay(2000) to tell the compiler that you want run Task.Delay(2000) asynchronous.
If you take a closer look in the example provided by you the compiler shows a warning:
This async methods lacks 'await'operators and will run synchronously [...]
This will hopefully demonstrate it better:
static async Task Main(string[] args)
{
var timer = Stopwatch.StartNew();
var t1 = LongTask();
var t2 = LongTask();
Console.WriteLine("Started both tasks in {0}", timer.Elapsed);
await Task.WhenAll(t1, t2);
timer.Stop();
Console.WriteLine("Tasks finished in {0}", timer.Elapsed);
}
async static Task LongTask()
{
await Task.Delay(2000);
}
Notice the change in return types of functions. Notice the output, too. Both task are waiting for something (in this case delay to expire) in parallel and at the same time, the Main function is able to continue running, printing text and then waiting for the outcome of those functions.
It is important to understand that the execution of an async function runs synchronously until it hits the await operator. If you don't have any await in an async function it will not run asynchronously (and compiler should warn about it). This is applied recursively (if you have several nested awaits) until you hit something that is actually going to be waited for. See example:
static async Task Main(string[] args)
{
var timer = Stopwatch.StartNew();
var t1 = LongTask(1);
Console.WriteLine("t1 started in {0}", timer.Elapsed);
var t2 = LongTask(2);
Console.WriteLine("Started both tasks in {0}", timer.Elapsed);
await Task.WhenAll(t1, t2);
timer.Stop();
Console.WriteLine("Tasks finished in {0}", timer.Elapsed);
}
async static Task LongTask(int id)
{
Console.WriteLine("[{0}] Before subtask 1", id);
await LongSubTask1();
Console.WriteLine("[{0}] Before subtask 2", id);
await LongSubTask2();
Console.WriteLine("[{0}] After subtask 1", id);
}
async static Task LongSubTask1(int id)
{
Console.WriteLine("[{0}] LongSubTask1", id);
await Task.Delay(1000);
}
async static Task LongSubTask2(int id)
{
Console.WriteLine("[{0}] LongSubTask2", id);
await Task.Delay(1000);
}
If you run it, you will see that the execution runs synchronously all the way down to Task.Delay call and only then it returns all the way back to the Main function.
In order to benefit from async/await, you have to use it all the way down to where it ends up calling some I/O (network, disk, etc.) you will need to wait for (or some other event that does not require constant polling to figure out, or artificially created like delay in that sample). If you need to do some expensive computation (that does not have anything async in it) without occupying some particular thread (say, UI thread in GUI application), you'd need to explicitly start new task with it, which at some later point you can await for to get its result.
I am trying to wrap my head around async await in C#. I have written this small windows console app that has two files.
Downloader.cs
namespace AsyncAwait
{
public class Downloader
{
public async Task DownloadFilesAsync()
{
// In the Real World, we would actually do something...
// For this example, we're just going to print file 0, file 1.
await DownloadFile0();
await DownloadFile1();
}
public async Task DownloadFile0()
{
int count = 0;
while (count < 100)
{
Console.WriteLine("Downloading File {0,1} ----> {1,3}%",0,count);
Thread.Sleep(10);
count++;
}
await Task.Delay(100);
}
public async Task DownloadFile1()
{
int count = 0;
while (count < 100)
{
Console.WriteLine("Downloading File {0,1} ----> {1,3}%", 1, count);
Thread.Sleep(10);
count++;
}
await Task.Delay(100);
}
}
}
Program.cs
namespace AsyncAwait
{
class Program
{
static void Main(string[] args)
{
Downloader d = new Downloader();
d.DownloadFilesAsync().Wait();
Console.WriteLine("finished");
}
}
}
In the output I see the file being downloaded one after the other (file1 followed by file2). I have sleep inside the while loop for both DownloadFile0 as well as DownloadFile1.
I would expect that they happen together just like a different thread would do instead of in a strictly sequential manner. In my understanding that is what async is all about? Is my understanding wrong? If now how do I fix this?
In your DownloadFilesAsync
You need to do this:
public async Task DownloadFilesAsync()
{
// In the Real World, we would actually do something...
// For this example, we're just going to print file 0, file 1.
var task1 = DownloadFile0();
var task2 = DownloadFile1();
await Task.WhenAll(task1, task2).
}
Basically, await means you wait for the execution of the task before you go to the next line. So let the tasks execute and then wait at the end with WhenAll.
Also, try to read about ConfigureAwait(false), it will save you from deadlocks:)
Update
Also, change Thread.Sleep to await Task.Delay(100); (to simulate file download, and use actually async function to do the file download)
Thread.Sleep means your main thread will sleep as soon as it hits this line and it won't yield, so your task will go through the whole loop before it finally awaits on this line: await Task.Delay(100); and execution goes to DownloadFile1.
On the other hand Task.Delay yields and execution will go to DownloadFile1 until it hits the first await.
Let me try and explain what you are doing, and hopefully you will see why things are happening sequentially.
Imagine you, yes you, are the main thread and you start executing the main function. You create a new Downloader then you see the DownloadFilesAsync() method so you go to it. You go to that method and then you see DownloadFile0() so you go to that method. You start doing the loop, you sleep for 10 ms in each loop iteration. Once the loop is completed, you do something. This is the important part: Here you decide you do not want to do the Delay. You ask that you want one of the threads in the threadpool to do the 100 ms of delay. Because you put the word await, you are also saying: "Hey, ask some thread in the threadpool to wait for 100 ms and when done, let me know. Do not do anything after this. Just let me know." Then since a threadpool thread will do the waiting of 100 ms, you return immediately to the line await DownloadFile0();. Here you also have an await so you do not go any further. You return immediately to the main method. Here the next thing for you to do is, since you already did d.DownloadFilesAsync() is to do the .Wait();. So you wait and do nothing else.
Sometime later, 100 ms later, you are interrupted: "Hey main thread, you asked one of the pool threads to wait for 100 ms. It is done. You can take it from here." So you go back to where you had left off which is: await Task.Delay(100); in DownloadFile0(). You proceed and there is nothing to do after this line except to return. So after this line you return to await DownloadFile0(); and since DownloadFile0() is completely done, you move to the next line which is await DownloadFile1();.
Therefore, DownloadFile1() is only started after everything is done in DownloadFile0(). Then you pretty much do the same thing in DownloadFile1(). You, the main, thread did all of the work. The only work you asked the thread-pool threads to do is Task.Delay(100); which is waiting 100 ms in each method. And in that time you were free, but you did nothing else but wait.
Thus all the work is sequential.
NOTE: It is possible even the Task.Delay(100) is done sequentially. The scheduler will call the IsCompleted method and if it is completed, it will not be done asynchronously..
If you were doing true asynchronous work like calling a web service to download a huge file, or some other IO work, while that is happening, you the main thread, instead of waiting could have been showing a nice progress bar to the user stating that you are alive and you are waiting for a file download. Or you could have been doing other work...you get the point.
I sometimes encounter code in the following form:
while (true) {
//do something
Thread.Sleep(1000);
}
I was wondering if this is considered good or bad practice and if there are any alternatives.
Usually I "find" such code in the main-function of services.
I recently saw code in the "Run" function in a windows azure worker role which had the following form:
ClassXYZ xyz = new ClassXYZ(); //ClassXYZ creates separate Threads which execute code
while (true) {
Thread.Sleep(1000);
}
I assume there are better ways to prevent a service (or azure worker role) from exiting.
Does anyone have a suggestion for me?
Well when you do that with Thread.Sleep(1000), your processor wastes a tiny amount of time to wake up and do nothing.
You could do something similar with CancelationTokenSource.
When you call WaitOne(), it will wait until it receives a signal.
CancellationTokenSource cancelSource = new CancellationTokenSource();
public override void Run()
{
//do stuff
cancelSource.Token.WaitHandle.WaitOne();
}
public override void OnStop()
{
cancelSource.Cancel();
}
This will keep the Run() method from exiting without wasting your CPU time on busy waiting.
An alternative approach may be using an AutoResetEvent and instantiate it signaled by default.
public class Program
{
public static readonly AutoResetEvent ResetEvent = new AutoResetEvent(true);
public static void Main(string[] args)
{
Task.Factory.StartNew
(
() =>
{
// Imagine sleep is a long task which ends in 10 seconds
Thread.Sleep(10000);
// We release the whole AutoResetEvent
ResetEvent.Set();
}
);
// Once other thread sets the AutoResetEvent, the program ends
ResetEvent.WaitOne();
}
}
Is the so-called while(true) a bad practice?
Well, in fact, a literal true as while loop condition may be considered a bad practice, since it's an unbrekeable loop: I would always use a variable condition which may result in true or false.
When I would use a while loop or something like the AutoResetEvent approach?
When to use while loop...
...when you need to execute code while waiting the program to end.
When to use AutoResetEvent approach...
...when you just need to hold the main thread in order to prevent the program to end, but such main thread just needs to wait until some other thread requests a program exit.
If you see code like this...
while (true)
{
//do something
Thread.Sleep(1000);
}
It's most likely using Sleep() as a means of waiting for some event to occur — something like user input/interaction, a change in the file system (such as a file being created or modified in a folder, network or device event, etc. That would suggest using more appropriate tools:
If the code is waiting for a change in the file system, use a FileSystemWatcher.
If the code is waiting for a thread or process to complete, or a network event to occur, use the appropriate synchronization primitive and WaitOne(), WaitAny() or WaitAll() as appropriate. If you use an overload with a timeout in a loop, it gives you cancelability as well.
But without knowing the actual context, it's rather hard to say categorically that it's either good, bad or indifferent. If you've got a daemon running that has to poll on a regular basis (say an NTP client), a loop like that would make perfect sense (though the daemon would need some logic to monitor for shutdown events occuring.) And even with something like that, you could replace it with a scheduled task: a different, but not necessarily better, design.
If you use while(true) you have no programmatic means of ending the loop from outside the loop.
I'd prefer, at least, a while(mySingletonValue) which would allow us to switch the loop as needed.
An additional approach would be to remove the functional behavior from the looping behavior. Your loop my still be infinite but it calls a function defined elsewhere. Therefore the looping behavior is completely isolated to what is being executed by the loop:
while(GetMySingletonValue())
{
someFunction();
}
In this way your singleton controls the looping behavior entirely.
There are better ways to keep the Azure Service and exit when needed.
Refer:
http://magnusmartensson.com/howto-wait-in-a-workerrole-using-system-timers-timer-and-system-threading-eventwaithandle-over-system-threading-thread-sleep
http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/azure-worker-role-exiting-safely/
It really depends on that //do something on how it determines when to break out of the loop.
In general terms, more appropriate way to do it is to use some synchronization primitive (like ManualResetEvent) to wait on, and the code that processes and triggers the break of the loop (on the other thread) to signal on that primitive. This way you don't have thread wasting resources by being scheduled in every second to do nothing, and is a much cleaner way to do it.
I personally don't like Thread.Sleep code. Because it locks the main thread. You can write something like this, if it is a windows application besides it allows you more flexibility and you can call it async:
bool switchControl = true;
while (switchControl) {
//do something
await Wait(1);
}
async void Wait(int Seconds)
{
DateTime Tthen = DateTime.Now;
do
{
Application.DoEvents(); //Or something else or leave empty;
} while (Tthen.AddSeconds(Seconds) > DateTime.Now);
}
I'm working on a Windows 8.1 store app in which the user can save text to a file.
I've been trying to understand how to best use async and await.
This is what I've come up with:
private async void userText_KeyDown(object sender, KeyRoutedEventArgs e)
{
if (e.Key == Windows.System.VirtualKey.Enter)
{
if (addUserImput)
{
userStringlist.Add(userBox.Text);
userBox.Text = "";
addUserImput = false;
}
await WriteToFileAsync();
addUserImput = true;
}
}
And the async-method looks like this:
private async Task WriteToFileAsync()
{
string name = "userStrings.txt";
var option = CreationCollisionOption.ReplaceExisting;
var folder = Windows.Storage.ApplicationData.Current.LocalFolder;
var file = await folder.CreateFileAsync(name, option);
await Windows.Storage.FileIO.WriteLinesAsync(file, userStringlist);
}
As soon as WriteToFileAsync reaches the await-keyword the execution will start over. In order to prevent duplicates in my list I had to add the if-statement.
It just strikes me as odd. I'm still new to this, so I might've missed something. Why does the keydown event resume from the top, doing work that has already been done?
My "workaround" works, I just don't get the logic behind the event's behaviour.
Yes, that's how asynchronous solutions work. When you hit your first actually asynchronous operation (in this case, CreateFileAsync) the method returns to its caller, which returns to its caller, and it eventually works it's way out of the entire method and back up to your application's message loop. It then continues on processing other UI messages. Some of those messages may be key down events (and they could end up being run before your asynchronous operation is completed). Other events could be things like paint events or mouse click events that lets your form do whatever it needs to interact with the user. This is what prevents it from freezing.
What you want to do is to prevent the given section of code that you have from being run concurrently. If this weren't asynchronous this is something that you would generally solve using the lock keyword, but that isn't an option for an asynchronous method. What you need is some method of preventing access to the code until any other executions of that code block finish. Fortunately there are tools available to do this. You could use a boolean, as you are, but this is somewhat fragile and fairly easy to make a mistake with as the complexity of the application grows. A Semaphore is specifically designed for this task:
private SemaphoreSlim semaphore = new SemaphoreSlim(1);
private async void Bar()
{
try
{
await semaphore.WaitAsync();
//do stuff
}
finally
{
semaphore.Release();
}
}
The SemaphoreSlim class has a WaitAsync method specifically designed for use in asynchronous methods, such as yours. You can wait until the semaphore is free, do your code, and then ensure that you release the semaphore when done so that other code can then move into the code block.
You may need to use handled = true in this case . check if http://msdn.microsoft.com/en-us/library/system.windows.forms.keyeventargs.handled(v=vs.110).aspx works
Microsoft just announced the new C# Async feature. Every example I've seen so far is about asynchronously downloading something from HTTP. Surely there are other important async things?
Suppose I'm not writing a new RSS client or Twitter app. What's interesting about C# Async for me?
Edit I had an Aha! moment while watching Anders' PDC session. In the past I have worked on programs that used "watcher" threads. These threads sit waiting for something to happen, like watching for a file to change. They aren't doing work, they're just idle, and notify the main thread when something happens. These threads could be replaced with await/async code in the new model.
Ooh, this sounds interesting. I'm not playing with the CTP just yet, just reviewing the whitepaper. After seeing Anders Hejlsberg's talk about it, I think I can see how it could prove useful.
As I understand, async makes writing asynchronous calls easier to read and implement. Very much in the same way writing iterators is easier right now (as opposed to writing out the functionality by hand). This is essential blocking processes since no useful work can be done, until it is unblocked. If you were downloading a file, you cannot do anything useful until you get that file letting the thread go to waste. Consider how one would call a function which you know will block for an undetermined length and returns some result, then process it (e.g., store the results in a file). How would you write that? Here's a simple example:
static object DoSomeBlockingOperation(object args)
{
// block for 5 minutes
Thread.Sleep(5 * 60 * 1000);
return args;
}
static void ProcessTheResult(object result)
{
Console.WriteLine(result);
}
static void CalculateAndProcess(object args)
{
// let's calculate! (synchronously)
object result = DoSomeBlockingOperation(args);
// let's process!
ProcessTheResult(result);
}
Ok good, we have it implemented. But wait, the calculation takes minutes to complete. What if we wanted to have an interactive application and do other things while the calculation took place (such as rendering the UI)? This is no good, since we called the function synchronously and we have to wait for it to finish effectively freezing the application since the thread is waiting to be unblocked.
Answer, call the function expensive function asynchronously. That way we're not bound to waiting for the blocking operation to complete. But how do we do that? We'd call the function asynchronously and register a callback function to be called when unblocked so we may process the result.
static void CalculateAndProcessAsyncOld(object args)
{
// obtain a delegate to call asynchronously
Func<object, object> calculate = DoSomeBlockingOperation;
// define the callback when the call completes so we can process afterwards
AsyncCallback cb = ar =>
{
Func<object, object> calc = (Func<object, object>)ar.AsyncState;
object result = calc.EndInvoke(ar);
// let's process!
ProcessTheResult(result);
};
// let's calculate! (asynchronously)
calculate.BeginInvoke(args, cb, calculate);
}
Note: Sure we could start another thread to do this but that would mean we're spawning a thread that just sits there waiting to be unblocked, then do some useful work. That would be a waste.
Now the call is asynchronous and we don't have to worry about waiting for the calculation to finish and process, it's done asynchronously. It will finish when it can. An alternative to calling code asynchronously directly, you could use a Task:
static void CalculateAndProcessAsyncTask(object args)
{
// create a task
Task<object> task = new Task<object>(DoSomeBlockingOperation, args);
// define the callback when the call completes so we can process afterwards
task.ContinueWith(t =>
{
// let's process!
ProcessTheResult(t.Result);
});
// let's calculate! (asynchronously)
task.Start();
}
Now we called our function asynchronously. But what did it take to get it that way? First of all, we needed the delegate/task to be able to call it asynchronously, we needed a callback function to be able to process the results, then call the function. We've turned a two line function call to much more just to call something asynchronously. Not only that, the logic in the code has gotten more complex then it was or could be. Although using a task helped simplify the process, we still needed to do stuff to make it happen. We just want to run asynchronously then process the result. Why can't we just do that? Well now we can:
// need to have an asynchronous version
static async Task<object> DoSomeBlockingOperationAsync(object args)
{
//it is my understanding that async will take this method and convert it to a task automatically
return DoSomeBlockingOperation(args);
}
static async void CalculateAndProcessAsyncNew(object args)
{
// let's calculate! (asynchronously)
object result = await DoSomeBlockingOperationAsync(args);
// let's process!
ProcessTheResult(result);
}
Now this was a very simplified example with simple operations (calculate, process). Imagine if each operation couldn't conveniently be put into a separate function but instead have hundreds of lines of code. That's a lot of added complexity just to gain the benefit of asynchronous calling.
Another practical example used in the whitepaper is using it on UI apps. Modified to use the above example:
private async void doCalculation_Click(object sender, RoutedEventArgs e) {
doCalculation.IsEnabled = false;
await DoSomeBlockingOperationAsync(GetArgs());
doCalculation.IsEnabled = true;
}
If you've done any UI programming (be it WinForms or WPF) and attempted to call an expensive function within a handler, you'll know this is handy. Using a background worker for this wouldn't be that much helpful since the background thread will be sitting there waiting until it can work.
Suppose you had a way to control some external device, let's say a printer. And you wanted to restart the device after a failure. Naturally it will take some time for the printer to start up and be ready for operation. You might have to account for the restart not helping and attempt to restart again. You have no choice but to wait for it. Not if you did it asynchronously.
static async void RestartPrinter()
{
Printer printer = GetPrinter();
do
{
printer.Restart();
printer = await printer.WaitUntilReadyAsync();
} while (printer.HasFailed);
}
Imagine writing the loop without async.
One last example I have. Imagine if you had to do multiple blocking operations in a function and wanted to call asynchronously. What would you prefer?
static void DoOperationsAsyncOld()
{
Task op1 = new Task(DoOperation1Async);
op1.ContinueWith(t1 =>
{
Task op2 = new Task(DoOperation2Async);
op2.ContinueWith(t2 =>
{
Task op3 = new Task(DoOperation3Async);
op3.ContinueWith(t3 =>
{
DoQuickOperation();
}
op3.Start();
}
op2.Start();
}
op1.Start();
}
static async void DoOperationsAsyncNew()
{
await DoOperation1Async();
await DoOperation2Async();
await DoOperation3Async();
DoQuickOperation();
}
Read the whitepaper, it actually has a lot of practical examples like writing parallel tasks and others.
I can't wait to start playing with this either in the CTP or when .NET 5.0 finally makes it out.
The main scenarios are any scenario that involves high latency. That is, lots of time between "ask for a result" and "obtain a result". Network requests are the most obvious example of high latency scenarios, followed closely by I/O in general, and then by lengthy computations that are CPU bound on another core.
However, there are potentially other scenarios that this technology will mesh nicely with. For example, consider scripting the logic of a FPS game. Suppose you have a button click event handler. When the player clicks the button you want to play a siren for two seconds to alert the enemies, and then open the door for ten seconds. Wouldn't it be nice to say something like:
button.Disable();
await siren.Activate();
await Delay(2000);
await siren.Deactivate();
await door.Open();
await Delay(10000);
await door.Close();
await Delay(1000);
button.Enable();
Each task gets queued up on the UI thread, so nothing blocks, and each one resumes the click handler at the right point after its job is finished.
I've found another nice use-case for this today: you can await user interaction.
For example, if one form has a button that opens another form:
Form toolWindow;
async void button_Click(object sender, EventArgs e) {
if (toolWindow != null) {
toolWindow.Focus();
} else {
toolWindow = new Form();
toolWindow.Show();
await toolWindow.OnClosed();
toolWindow = null;
}
}
Granted, this isn't really any simpler than
toolWindow.Closed += delegate { toolWindow = null; }
But I think it nicely demonstrates what await can do. And once the code in the event handler is non-trivial, await make programming much easier. Think about the user having to click a sequence of buttons:
async void ButtonSeries()
{
for (int i = 0; i < 10; i++) {
Button b = new Button();
b.Text = i.ToString();
this.Controls.Add(b);
await b.OnClick();
this.Controls.Remove(b);
}
}
Sure, you could do this with normal event handlers, but it would require you to take apart the loop and convert it into something much harder to understand.
Remember that await can be used with anything that gets completed at some point in the future. Here's the extension method Button.OnClick() to make the above work:
public static AwaitableEvent OnClick(this Button button)
{
return new AwaitableEvent(h => button.Click += h, h => button.Click -= h);
}
sealed class AwaitableEvent
{
Action<EventHandler> register, deregister;
public AwaitableEvent(Action<EventHandler> register, Action<EventHandler> deregister)
{
this.register = register;
this.deregister = deregister;
}
public EventAwaiter GetAwaiter()
{
return new EventAwaiter(this);
}
}
sealed class EventAwaiter
{
AwaitableEvent e;
public EventAwaiter(AwaitableEvent e) { this.e = e; }
Action callback;
public bool BeginAwait(Action callback)
{
this.callback = callback;
e.register(Handler);
return true;
}
public void Handler(object sender, EventArgs e)
{
callback();
}
public void EndAwait()
{
e.deregister(Handler);
}
}
Unfortunately it doesn't seem possible to add the GetAwaiter() method directly to EventHandler (allowing await button.Click;) because then the method wouldn't know how to register/deregister that event.
It's a bit of boilerplate, but the AwaitableEvent class can be re-used for all events (not just UI). And with a minor modification and adding some generics, you could allow retrieving the EventArgs:
MouseEventArgs e = await button.OnMouseDown();
I could see this being useful with some more complex UI gestures (drag'n'drop, mouse gestures, ...) - though you'd have to add support for cancelling the current gesture.
There are some samples and demos in the CTP that don't use the Net, and even some that don't do any I/O.
And it does apply to all multithreaded / parallel problem areas (that already exist).
Async and Await are a new (easier) way of structuring all parallel code, be it CPU-bound or I/O bound. The biggest improvement is in areas where before C#5 you had to use the APM (IAsyncResult) model, or the event model (BackgroundWorker, WebClient). I think that is why those examples lead the parade now.
A GUI clock is a good example; say you want to draw a clock, that updates the time shown every second. Conceptually, you want to write
while true do
sleep for 1 second
display the new time on the clock
and with await (or with F# async) to asynchronously sleep, you can write this code to run on the UI thread in a non-blocking fashion.
http://lorgonblog.wordpress.com/2010/03/27/f-async-on-the-client-side/
The async extensions are useful in some cases when you have an asynchronous operation. An asynchronous operation has a definite start and completion. When asynchronous operations complete, they may have a result or an error. (Cancellation is treated as a special kind of error).
Asynchronous operations are useful in three situations (broadly speaking):
Keeping your UI responsive. Any time you have a long-running operation (whether CPU-bound or I/O-bound), make it asynchronous.
Scaling your servers. Using asynchronous operations judiciously on the server side may help your severs to scale. e.g., asynchronous ASP.NET pages may make use of async operations. However, this is not always a win; you need to evaluate your scalability bottlenecks first.
Providing a clean asynchronous API in a library or shared code. async is excellent for reusability.
As you begin to adopt the async way of doing things, you'll find the third situation becoming more common. async code works best with other async code, so asynchronous code kind of "grows" through the codebase.
There are a couple of types of concurrency where async is not the best tool:
Parallelization. A parallel algorithm may use many cores (CPUs, GPUs, computers) to solve a problem more quickly.
Asynchronous events. Asynchronous events happen all the time, independent of your program. They often do not have a "completion." Normally, your program will subscribe to an asynchronous event stream, receive some number of updates, and then unsubscribe. Your program can treat the subscribe and unsubscribe as a "start" and "completion", but the actual event stream never really stops.
Parallel operations are best expressed using PLINQ or Parallel, since they have a lot of built-in support for partitioning, limited concurrency, etc. A parallel operation may easily be wrapped in an awaitable by running it from a ThreadPool thread (Task.Factory.StartNew).
Asynchronous events do not map well to asynchronous operations. One problem is that an asynchronous operation has a single result at its point of completion. Asynchronous events may have any number of updates. Rx is the natural language for dealing with asynchronous events.
There are some mappings from an Rx event stream to an asynchronous operation, but none of them are ideal for all situations. It's more natural to consume asynchronous operations by Rx, rather than the other way around. IMO, the best way of approaching this is to use asynchronous operations in your libraries and lower-level code as much as possible, and if you need Rx at some point, then use Rx from there on up.
Here is probably a good example of how not to use the new async feature (that's not writing a new RSS client or Twitter app), mid-method overload points in a virtual method call. To be honest, i am not sure there is any way to create more than a single overload point per method.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
namespace AsyncText
{
class Program
{
static void Main(string[] args)
{
Derived d = new Derived();
TaskEx.Run(() => d.DoStuff()).Wait();
System.Console.Read();
}
public class Base
{
protected string SomeData { get; set; }
protected async Task DeferProcessing()
{
await TaskEx.Run(() => Thread.Sleep(1) );
return;
}
public async virtual Task DoStuff() {
Console.WriteLine("Begin Base");
Console.WriteLine(SomeData);
await DeferProcessing();
Console.WriteLine("End Base");
Console.WriteLine(SomeData);
}
}
public class Derived : Base
{
public async override Task DoStuff()
{
Console.WriteLine("Begin Derived");
SomeData = "Hello";
var x = base.DoStuff();
SomeData = "World";
Console.WriteLine("Mid 1 Derived");
await x;
Console.WriteLine("EndDerived");
}
}
}
}
Output Is:
Begin Derived
Begin Base
Hello
Mid 1 Derived
End Base
World
EndDerived
With certain inheritance hierarchies (namely using command pattern) i find myself wanting to do stuff like this occasionally.
here is an article about showing how to use the 'async' syntax in a non-networked scenario that involves UI and multiple actions.