title: Is async/await pattern irrelevant without threading or asynchronous devices?
body: <p><strong>Edit</strong> - After reading the three answers below, I've realized that I'm asking nonsense ! Apologies for wasting some of your precious time, and thanks for clarifying alot of misunderstandings, really! :) </p>
  
  <p>I were assuming <a href="https://stackoverflow.com/a/18306740/2410892">apples and pipe wrenches</a> were the same thing in the way async/await and threads are solution for similar concerns. <code>Async/await</code> and <code>Threads</code> both addresses UI responsiveness, <strong>but not in the same way</strong>. The former is a pattern to be used when several desired results can be gathered asynchronously (in order to improve user experience for example), hence why it's called "async". Heavy works, those that take several seconds to hours has to be off loaded on another thread to keep UI responsive. Those two are completely different concerns.</p>
  
  <p>No matter how I may edit this question, there is no way to ask such async/await with or without threading concern as they are completely different things, can be used together (in so many ways) or separately. The statement .2 below said it all (apart a "invocation" misconception) but I didn't truely understood its true meaning from the start.</p>
  
  <p>I guess I should have deleted the question from the moment I had doubts, but I couldn't understand how far it was a dumb one before actually reading some answers. However, this may also help other to have a better understanding of what async/await is about.</p>
  
  <p><sub>By the way, I don't know what answer to mark as answer as they all have valuable informations.</sub></p>
  
  <hr>
  
  <p><strong>Original post</strong>:</p>
  
  <p>It's fair to note that I'm <em>"yet another async/await beginner"</em>. However, What I've understood so far are:</p>
  
  <ol>
  <li>async/await doesn't create <code>threads</code> ! Never ! They run on the same thread as the caller.</li>
  <li>async/await are not parallel tasks. They just defines a pattern where an async block of code get executed the moment an await is invoked at caller level (or so - I know my understanding is slightly wrong, but that's how I can clearly picture it in mind)</li>
  <li>No code block is executed asynchronuously if that block doesn't contain an await keyword.</li>
  <li>async/await appears to work well with some I/O tasks, but seems not that wonderful on most high CPU computations.</li>
  <li>async/await seems to fail with <code>Thread.Sleep</code> (should use <code>Task.Delay</code> instead) or in case of <code>Exception</code> with <code>Finally</code> block.</li>
  </ol>
  
  <p>Based on the above, and to simplify things, I think async/await is just an improved form of <strong><code>goto</code></strong>, capable of jumping from a method step to another method step, because the <code>goto</code> call can "fly" (be delayed) until an await is encountered ! (sorry to simplify things that far)</p>
  
  <p>I've tested both I/O and CPU codes without additional threads, both heavy, and both produced <strong>unresponsive</strong> UI until everything was completed.</p>
  
  <p><strong>My observaton is</strong>:</p>
  
  <p>Without <em>asynchronous capable</em> things like :</p>
  
  <ul>
  <li>threads explicitely defined using one of the numerous <code>.net</code> objects in the framework, or their members that create threads on their own</li>
  <li>or <code>IO devices</code> that are designed to work asynchronously from the start at hardware level (CPU)</li>
  </ul>
  
  <p><code>async/await</code> are just plain <strong>synchronous</strong> patterns; meaning, there is no asynchronous-like thing anywhere with just <code>async/await</code> keywords.</p>
  
  <blockquote>
    <p><strong>The question is</strong>: is the above observation true, or am I missing some important thing about <code>async/await</code> ?</p>
  </blockquote>
  
  <hr>
  
  <p>Side notes :</p>
  
  <p><sub>I've read this <a href="http://blog.stephencleary.com/2013/11/there-is-no-thread.html" rel="nofollow noreferrer">blog post</a> (<em>There Is No Thread</em>, Stephen Cleary's Blog). He states that there is no thread (totally agree) but it doesn't contradict with my observation that, at pure programmer code level without asynchronous devices involved, you can't have a responsive UI unless you delegate the heavy tasks in another thread. My concern is not the <em>awaitable</em> aspect of the pattern, as I said, it's like a flying goto; I want to make sure I'm not using <code>async/await</code> blindly just for the sake of using something new.</sub></p>
  
  <p><sub><code>.ConfigureAwait(false)</code> : seems to involve a ThreadPool to me, which is why the UI thread is still responsive...</sub></p>