What is the meaning of the Await + Async call

maximechal

Dear all,

short: What sense does it make to write:
await xxxxAsync();
If await waits for completion then I would rather save some readability and use:
xxx();
Or is something more complex happening in the back ?

long: I am developing an demo for Hololens and I need to use some networking elements. After realizing with some sadnees that the Unity networking code is not compatible with the UWP infrastructure, I collected some sample from the internet and came up with something that is working for me. However, I have to use some code I am not confortable with (I come from VHDL/linux C for realtime). In particular, the async call are bothering me. I use the following:
await socket.BindEndpointAsync(HlocalhostIp, localPort);
But I fail to understand the point of the Async together with the Await. Is it going to suspend my main thread until the operation is finished ? Is it going to continue executing the next lines until the function return and then wait for completion ?
If it waits for the completion, why not providing a "non" Async version of the call ? Or is it an advertisment move to push poeple to use this new programming style ?

Thanks to anyone that can provide a bit of explanation (please dont point to the official documentation)

Best regards

mtaulty

This is really a C# programming language topic in itself and you can find answers around this in the C# documentation and I doubt that I can really add much to those docs but here's some notes...

Many of the UWP APIs are asynchronous - it was a conscious design choice to avoid the sorts of problems that have been encountered in the past where potentially long-running operations have been placed behind synchronous APIs which can lead to applications that don't behave well (the notorious "(not responding)").

The UWP APIs though are language agnostic with their type system "projected" into various languages including C# where the projection of the asynchronous nature of an API is handled by making it match up with the C# awaitable pattern.

So, the language projection 'magic' in UWP makes sure that an asynchronous method like BindEndpointAsync shows up in C# as returning something like an IAsyncAction interface which becomes awaitable via an extension method like this one.

If you look at the TaskAwaiter that gets returned from the extension method here then you'll notice that it meets the "awaitable" pattern because it has an event that can tell you when it is completed, a flag to check for completion and a method to potentially gather results.

You can manually then call this method, grab the return value, sync up to the event handler, handle the "completed" event, remove the event handler, grab the results and try to do all of that correctly in the presence of possible exceptions & the possibility that the event handler might be called on a different thread from the one that you made your call on.

Or...you can use "await" which tells the compiler to rewrite your function into the "calling piece" and the "continuation piece". It does all that manual stuff for you and makes your code look like it's just regular, serial execution from one line to the next when it's really a state machine using callbacks. It also does the right thing around exceptions & can (in the right circumstances & under your control) ensure that the calling thread context is used to execute the "continuation".

The compiler asks that if you do use "await" inside of a function then there's a limitation around what you can return from the function. The way I think of this is that if my function calls async functions using "await" then my function itself becomes asynchronous and the function also has to be marked "async" to say so and convention is to name it to end with "Async" to help developers spot it.

That's a long answer and, no doubt, other people can chip in and point out my errors & that I haven't been complete in my description but I'm hoping that you would see that for an async function BindEndpointAsync making a call like;

BindEndpointAsync();
int x = 10;

is very different to awaiting a call like;

await BindEndpointAsync();
int x = 10;

and that nothing "suspends" your calling thread but in the first case it's going to immediately continue to execute the assignment into x whereas in the second case it will be an asynchronous callback possibly posted back into the same thread execution context which will execute that assignment at a later point in time.

What happens to your calling thread kind of 'depends' on where it came from in the first place I think.

I hope that helps and sorry for pointing to some of the official documentation :-)