29

I've been reading a lot about async and await, and at first I didn't get it because I didn't properly understand threading or tasks. But after getting to grips with both I wonder: why use async/await if you're comfortable with threads?

The asynchronousy of async/await can be done with Thread signaling, or Thread.Join() etc. Is it merely for time saving coding and "less" hassle?

James Jeffery
  • 12,093
  • 19
  • 74
  • 108
  • It's for time saving and simplicity. Also, tasks **are part of** async/await. – It'sNotALie. Aug 18 '13 at 12:15
  • 1
    possible duplicate of [Difference between the TPL & async/await (Thread handling)](http://stackoverflow.com/questions/10285159/difference-between-the-tpl-async-await-thread-handling) – Daniel Mann Aug 18 '13 at 13:15

5 Answers5

24

Yes, it is a syntactic sugar that makes dealing with threads much easier, it also makes the code easier to maintain, because the thread management is done by run-time. await release the thread immediately and allows that thread or another one to pick up where it left off, even if done on the main thread.

Like other abstractions, if you want complete control over the mechanisms under the covers, then you are still free to implement similar logic using thread signaling, etc.

If you are interested in seeing what async/await produces then you can use Reflector or ILSpy to decompile the generated code.

Read What does async & await generate? for a description of what C# 5.0 is doing on your behalf.

Karl Anderson
  • 34,606
  • 12
  • 65
  • 80
  • 1
    And for a nice description of WHY `async` `await` is so nice, see this link: http://tirania.org/blog/archive/2013/Aug-15.html – Anton Aug 18 '13 at 12:32
16

If await was just calling Task.Wait we wouldn't need special syntax and new APIs for that. The major difference is that async/await releases the current thread completely while waiting for completion. During an async IO there is no thread involved at all. The IO is just a small data structure inside of the kernel.

async/await uses callback-based waiting under the hood and makes all its nastiness (think of JavaScript callbacks...) go a way.

Note, that async does not just move the work to a background thread (in general). It releases all threads involved.

usr
  • 168,620
  • 35
  • 240
  • 369
11

Comparing async and await with threads is like comparing apples and pipe wrenches. From 10,000 feet they may look similar, but they are very different solutions to very different problems.

async and await are all about asynchronous programming; specifically, allowing a method to pause itself while it's waiting for some operation. When the method pauses, it returns to its caller (usually returning a task, which is completed when the method completes).

I assume you're familiar with threading, which is about managing threads. The closest parallel to a thread in the async world is Task.Run, which starts executing some code on a background thread and returns a task which is completed when that code completes.

async and await were carefully designed to be thread-agnostic. So they work quite well in the UI thread of WPF/Win8/WinForms/Silverlight/WP apps, keeping the UI thread responsive without tying up thread pool resources. They also work quite well in multithreaded scenarios such as ASP.NET.

If you're looking for a good intro to async/await, I wrote up one on my blog which has links to additional recommended reading.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810
6

There is a difference between the Threads and async/await feature.

Think about a situation, where you are calling a network to get some data from network. Here the Thread which is calling the Network Driver (probably running in some svchost process) keeps itself blocked, and consumes resources.

In case of Async/await, if the call is not network bound, it wraps the entire call into a callback using SynchronizationContext which is capable of getting callback from external process. This frees the Thread and the Thread will be available for other things to consume.

Asynchrony and Concurrency are two different thing, the former is just calling something in async mode while the later is really cpu bound. Threads are generally better when you need concurrency.

I have written a blog long ago describing these features . C# 5.0 vNext - New Asynchronous Pattern

abhishek
  • 2,975
  • 23
  • 38
  • Concurrency is a general term and means doing more than one thing at a time, hence asynchrony is a form of concurrency. What you meant with concurrency is parallelism. [link](http://abusanad.net/2016/06/21/insights-on-net-concurrency-introduction/) – user1912383 Jul 17 '16 at 09:28
4

async/await does not use threads; that's one of the big advantages. It keeps your application responsive without the added complexity and overhead inherent in threads.

The purpose is to make it easy to keep an application responsive when dealing with long-running, I/O intensive operations. For example, it's great if you have to download a bunch of data from a web site, or read files from disk. Spinning up a new thread (or threads) is overkill in those cases.

The general rule is to use threads via Task.Run when dealing with CPU-bound operations, and async/await when dealing with I/O bound operations.

Stephen Toub has a great blog post on async/await that I recommend you read.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • 3
    `async/await` does not use threads? Where is the documentation of this? – Karl Anderson Aug 18 '13 at 13:52
  • 3
    It doesn't by default in Winforms/WPF. You can certainly instruct it to use threads, of course. See `ConfigureAwait`. – Daniel Mann Aug 18 '13 at 13:59
  • 2
    Just read some of the docs posted by members above. Async/Await does nothing at all except inscruct the compiler that some async operation might occur in the following code. await SomeMethodAsync(), however can do whatever it feels like, it's up to the creator of SomeMethodAsync() to decide how to handle asynchonicity, and if he wants to use threads, then threads it is. Funny thing, Stephen Toub in his post you talked about explained all this very nicely. – Robert Hoffmann Aug 18 '13 at 14:26
  • Btw the post from Stephen Toub is really great, simple explanations and lots of cool links for digging further. MS TAP doc is quite good too. – Robert Hoffmann Aug 18 '13 at 14:33