Asynchrony and multithreading are both forms of concurrency:
- Concurrency: doing more than one thing at a time.
- Asynchrony: starting an operation and freeing up the current thread to do other things until that operation completes.
- Parallelism / multithreading: using multiple threads to do multiple things at the same time.
I was looking at the difference between JavaScript's single-threaded asynchronous processing and C#'s threaded approach to asynchronous processing
I believe that my answer to that question misled you a bit. When I talk about "asynchronously multi-threaded", I mean that the asynchrony exists within a multi-threaded environment. I do not mean that the asynchrony is implemented using multi-threading.
JavaScript is (for now) locked into a single-threaded model (setting aside for the moment things like web workers which are kind of like threads). So, asynchrony is naturally done all on a single thread. Note that pure asynchrony does not require a thread for the asynchronous operation; e.g., when you do a web API call, there's no thread that has to sit, waiting for the response to come back. Node.js (and browser JavaScript for that matter) use similar techniques to the ones in my post There Is No Thread, plus a threadpool to wrap a small number of blocking APIs.
The important thing to note here is that asynchrony does not require a thread. It is a form of concurrency that can be threadless, in principle. On the server side, this permits a great degree of scalability.
JavaScript stops there, at least for now. Node.js scales quite well on a single thread (not counting the thread pool), since it enforces asynchrony. ASP.NET takes a different approach: asynchrony has historically been a pain to use, so ASP.NET multi-threads first and then allows asynchronous or synchronous code; modern services can use asynchrony in that multi-threaded environment for even more scalability.
It seems to me that 'asynchronous coding' could sum up the entirety of 'using threads' in a language like C# or Java. Is this the case?
No. There is one class of work that does not fit well with asynchrony: CPU-bound algorithms. In this case, your "work" has actual CPU code that it must run on an actual CPU. If you're doing something like that, you need real threads. In this case, you'd want parallelism rather than asynchrony. Parallelism is slowly coming to JavaScript, but they're starting at a very low level and it will be quite some time before high-level parallelism is a viable option.
Side note: C# code can choose to run asynchronous code all on one thread. In fact, this is the default environment for client-side apps (UI apps on desktop/mobile). The multi-threaded asynchronous environment is generally only used on the server, e.g., ASP.NET.
My understanding of threads is code that executes on 2 separate processors at the same time
It can. This depends on the cores in the machine and what else the machine is doing. .NET provides high-level parallelism abstractions for splitting up your work into chunks and distributing those among threads, where the threads run on cores, and doing all of this in a highly intelligent and adaptive manner. JavaScript currently has no parallelism support like this.
It seems to me that point 2/3 are effectively handling asynchronous code in exactly the same logical manner that I would have with JavaScript.
Yes, except for the fact that JavaScript asynchronous code cannot be CPU-bound. E.g., you could use parallelism on .NET to calculate a fractal; you can't do this using only async/await (regardless of language).
From my inexperienced perspective with C#, it seems that asynchronous coding in JavaScript has many similarities to multi-threaded coding in C#.
From a high-level perspective, yes: they're both forms of concurrency.
If you mean that async/await in JavaScript is similar to async/await in C#, then yes, they're practically the same thing. async/await are used to implement asynchrony in both languages.
Though with different use-cases... The one difference I can see is that code in JavaScript never executes simultaneously with other code, whereas in C# it might - is this where the idea of 'thread safety' comes from? i.e. a thread's state can't be altered by operations on another thread (I think)...
Yes, any time you have multi-threading, you need to ensure thread safety. So, any kind of parallel code in C# needs to ensure it is threadsafe. Asynchronous code in a multi-threaded environment can also run into thread safety issues, but that's more rare (most asynchronous code is serial, which can have no thread safety issues).
