Multitasking, parallel processing, and concurrency in Swift
It has been a very long time since computers have executed code in a simple, linear manner. Even back in the 1950s, most used a system of interrupts or traps to handle errors, input/output, and other features, although those weren’t considered to be multitasking.
In computers with a single processor core, multitasking was a way of cheating to give the impression that the processor was doing several things at once, when in fact all it was doing was switching rapidly between two or more different programs. There are two fundamental models for doing that:
When a processor switches from one task to the next, the current task state must be saved so that it can be resumed later. Once that’s complete, the next task is loaded to complete what’s known as a context switch. That incurs overhead, both in terms of processing and in memory storage. Inevitably, switching between lightweight tasks has less overhead. There have been different strategies adopted to determine the optimum size of tasks and overhead imposed by context switching, and terminology differs between them, variously using words such as processes, threads and even fibres, which can prove thoroughly confusing.
Preemptive multitasking was championed on larger computers and in Unix, but was seldom attempted in personal computers until the mid-1980s. When the Macintosh was released forty years ago, its Motorola 68000 processor had insufficient memory and was short of computing power to make it a good candidate for multitasking. Andy Hertzfeld wrote Switcher for Classic Mac OS in 1984-85 to enable the user to switch between apps, and that led to MultiFinder in 1987, bringing cooperative multitasking.
