Asynchronous programming

Left to myself I probably would have called it "Concurrent Programming". There are university courses in "Concurrent and Parallel Programming. There are C# books with titles that include these words.

The game is this. Most programmers learn to write programs that expect a single thread of execution. They run from start to finish and only ever do one thing at a time. Concurrent and Parallel programming breaks with that model. Now we can have multiple threads of execution, and most importantly issues where they either conflict or need to cooperate.

Some of this is related to the availability of multiple cores in modern processors. It is an interest in working with multiple cores that brings many people to this arena. I assert that this is of little importance and ought to be ignored almost entirely -- at least to start. Systems with threads (or tasks, or whatever you want to call them) run on a uniprocessor and have all of the issues and methods you will need to master with multiple cores in the game.

If you deal with this sort of thing outside of C# (and outside of the Windows environment for that matter), you will find that the words "thread" and "task" may be used differently and sometimes interchangeably. Both words have a definite meaning in the context of C# -- but you should be warned that there is, as always, possible confusion of terms when you range afield.

This is a difficult topic. There are many surprises for people who have only ever written single path code (which is all of us at some point in our journey). This is a big part of what people who work on operating system code deal with. Various programming libraries, API, and abstractions have been written to try to hide and/or organize some of the details. The async/await scheme in C# is one attempt to organize the use of multiple tasks.