C# is a synchronous language, i.e process will block UI until result comes, now trouble is; this async with await looks like same thing as synchronous.
async + await = synch
I do understand the caller moves on, i.e the main thread is released.
C# is a synchronous language, i.e process will block UI until result comes, now trouble is; this async with await looks like same thing as synchronous.
async + await = synch
I do understand the caller moves on, i.e the main thread is released.
You can avoid performance bottlenecks and enhance the overall responsiveness of your application by using asynchronous programming.
However, traditional techniques for writing asynchronous applications can be complicated, making them difficult to write, debug, and maintain.
Visual Studio 2012 introduces a simplified approach, async programming, that leverages asynchronous support in the .NET Framework 4.5 and the Windows Runtime.
The compiler does the difficult work that the developer used to do, and your application retains a logical structure that resembles synchronous code. As a result, you get all the advantages of asynchronous programming with a fraction of the effort.
MSDN documentation here
C# is a synchronous language, i.e process will block UI until result comes
1) C# has nothing to do with the UI. The UI is implemented as a framework, and language agnostic.
2) Just counting the desktop, there is at least 2 UI framework, there is no "UI"
3) You are right, the 2 out of the box frameworks has thread affinity, and there is one main message pump. (btw nothing prevents you to do as many as you want, just your controls created in each must be accessed on that one exclusively, called "serialization" and it is a well known multiprogramming design pattern.
Now back to the main topic in the title.
Obviously you understand how async / await work. What is your misunderstanding what we can mean on asynchronous.
Please note: when you use async/await, it does not block the thread. After the async-ed execution completed that is the continuation in the code flow. If it would be implemented as a completion handler, or a callback, everyone would see what is it. Now it is written as the next lines of the code. I admit it can mislead one, but is is more convenient than writing (inline) completion handlers, especially if you have say 5 async operations in a row, then you must nest the completions in 4 levels. That is what C# compiler generates for you using async/await, and let you to write the code in a line by line matter.
Anyway, as you wrote
I do understand the caller moves on, i.e the main thread is released.
so it's async.