I'm playing around with async and await, and they seem pretty intuitive, but some of the things I'm reading about these keywords doesn't make sense to me. In fact, some of it seems to me to be flat-out wrong, or at least misleading, even though it's coming straight from Microsoft. Consider the code below:namespace AsyncExample2{    public partial class Form1 : Form    {        public Form1()        {            InitializeComponent();        }        private async void button1_Click(object sender, EventArgs e)        {               var t=new Task<int>(longRunningWork);            t.Start();             int r= await t;            textBox1.Text += (r.ToString());        }        int longRunningWork()        {            Thread.Sleep(15000);             return (new Random()).Next(10);        }    }}This is from a WinForms example application I created with a GUI consisting of a single button and a single textbox. When you press the button, 15 seconds later, a random digit is appended to the text in the textbox. During this 15 second period, the GUI remains interactive, e.g. the form can be maximized/minimized/moved. The button can even be clicked again.The most basic way that this code seems to contradict what Microsoft says about await / async is that, according to them, my call to t.Start() should not be necessary. Consider the very first statement of the article at https://msdn.microsoft.com/en-us/library/hh696703.aspx: [i]n an async method, tasks are started when theyre created. This does not seem to be the case in this particular async method (button1_Click), though I have seen it happen in other contexts. Second, I've read a lot of what I would describe as aggressive attempts to differentiate between the old thread-based model of parallelism and async / await, and, like the All New! labels often applied to product packaging by corporate marketing departments, these attempts at differentiation seem to contain some unjustified bluster. Consider the statement that the async and await keywords don't cause additional threads to be created (from https://msdn.microsoft.com/en-us/library/hh191443.aspx). This is not my observation; if I inspect Thread.CurrentThread.ManagedThreadId, I can see that longRunningWork() is not running on the GUI thread, though button1_Click certainly is. Furthermore, if I click the button rapidly in succession, and inspect Thread.CurrentThread.ManagedThreadId at the call to Thread.Sleep(), I see various, different managed thread IDs. And if I try to add anything to longRunningWork() that affects the GUI (say, sets textBox1.Text), I get the typical illegal cross-thread call error.Can someone help me reconcile these seeming inconsistencies? My hunch is that the first inconsistency I highlight is a relatively minor example of sloppiness (though I'd really like to know when I need to call Start() manually). The second inconsistency, I suspect, is just pedantry. People who know a little bit about async / await like to correct noobs who can't talk about these keywords without thinking in terms of threads. I get it; it's a different model of parallelism with a wholly different way of thinking. At the same time, though, it's a definite oversell to say that the async and await keywords don't cause additional threads to be created. The debugger implies otherwise. I suppose that technically it's possible that the threads I'm seeing are being grabbed from some sort of pool that exists throughout the program's execution. If that's the case, then, technically, nothing is getting created by async / await. This seems pretty trivial to me, and I'm not aware that WinForms programs have an ASP.NET-style thread pool.
C# async/await: Pedantry vs. the Debugger
.net;multithreading;async;asynchronous programming