3 ms·
async/await is for the concurrent stuff and threads are for the parallel stuff. Two different things. If your code is I/O-bound, use async/await. If your code
by pow_pp_-1_v 6y ago
async/await is for the concurrent stuff and threads are for the parallel stuff. Two different things. If your code is I/O-bound, use async/await. If your code is processor-bound thing, use threads.
- GordonS 6y agoAsync/await paradigms exist in several languages, but with C#, async/await is generally considered the "modern" and unified way to handle both IO bound and CPU bound tasks. The runtime will generally schedule IO bound tasks to run on the threadpool.
- pow_pp_-1_v 6y ago> The runtime will generally schedule IO bound tasks to run on the threadpool. Well, that's not correct. Unless you explicitly call Task.Run or Task.Start (or other similar methods) no new thread is created. The compiler generated state machines don't require the threading mechanism to work. In fact the overhead for async/await is mostly the extra code generated for the state machine and error handling. At runtime, there's no thread switching overhead.
- GordonS 6y agoYes, I meant using Task.Run; I was simplifying, as I'd assumed (wrongly) you were familiar with async/await from another language. Otherwise, from memory, the runtime spec doesn't actually guarantee that await won't run on a threadpool thread - it will under certain circumstances. And then there are further nuances if there is a synchronisation context and ConfigureAwait(false) is used, as the continuation will be scheduled on a threadpool thread.