Concurrency and Asynchronous Programming: a Detailed Overview 4 There's not a lot of code in this chapter, so we're off to a soft start. It's a good time to make a cup of tea, relax, and get comfortable, as we're about start this journey together. Technical requirements All examples will be written in Rust, and you have two alternatives for running the examples: Write and run the examples we'll write on the Rust playground Install Rust on your machine and run the examples locally (recommended) The ideal way to read this chapter is to clone the accompanying repository ( https://github. com/Packt Publishing/Asynchronous-Programming-in-Rust/tree/main/ ch01/a-assembly-dereference ) and open the ch01 folder and keep it open while you read the book. There, you'll find all the examples we write in this chapter and even some extra information that you might find interesting as well. Y ou can of course also go back to the repository later if you don't have that accessible right now. An evolutionary journey of multitasking In the beginning, computers had one CPU that executed a set of instructions written by a programmer one by one. No operating system (OS), no scheduling, no threads, no multitasking. This was how computers worked for a long time. We're talking back when a program was assembled in a deck of punched cards, and you got in big trouble if you were so unfortunate that you dropped the deck onto the floor. There were operating systems being researched very early and when personal computing started to grow in the 80s, operating systems such as DOS were the standard on most consumer PCs. These operating systems usually yielded control of the entire CPU to the program currently executing, and it was up to the programmer to make things work and implement any kind of multitasking for their program. This worked fine, but as interactive UIs using a mouse and windowed operating systems became the norm, this model simply couldn't work anymore. Non-preemptive multitasking Non-preemptive multitasking was the first method used to be able to keep a UI interactive (and running background processes). This kind of multitasking put the responsibility of letting the OS run other tasks, such as responding to input from the mouse or running a background task, in the hands of the programmer. Typically, the programmer yielded control to the OS.