Chapter 11. Threading
In This Chapter
Threads grew out of the need to do, or appear to do, many things at the same time. Before threads, the finest granularity at which the OS could schedule was at the process level. Programmers worried about spawning processes and tweaking the priority of processes. Starting up a process incurred much overhead, it was heavy, and communicating between processes was inefficient.
On the Unix platform, fork() and exec() allowed the programmer to split the execution path of a program into two pieces without much of the overhead of starting a new process. Probably most importantly, fork() and exec() allowed a programmer to easily share data between two different paths of execution. The problem became one of synchronization. With the ease of splitting a process came the responsibility of knowing how and when the operating system would schedule each path of execution.
For many reasons, most all modern operating systems adopted the idea of preemptive scheduling. With preemptive scheduling, an operating system does not allow one process or path of execution to dominate the system. Rather, it preempts or interrupts each process or path of execution for a small time-slice so that other processes have a chance to use the CPU. This was a good thing, because the machine locked up less frequently because a misbehaving process could not take over the CPU. However, sharing data truly became an issue. A method needed to be devised to allow the programmer to communicate to the operating system when it was safe to access shared data. What started out with the simple synchronization primitives of P() and V() (proposed by Dijkstra) grew into synchronization algorithms that became events, mutexes, semaphores, read/write locks, and critical sections.
Using fork() and exec() became unwieldy when trying to do much more than two or three things at one time. In addition, these APIs were not natively supported for the Windows programmer. Out of this, the concept of threads was born. Threads did not carry as much overhead (lighter weight) as a process. Threads had access to all of the same address space as the parent process. The idea of a thread was easier to grasp than a forked process, and threads were natively supported by the operating system. Threads provided the operating system with a scheduling unit, and they provided the programmer a hook into the operating system to control the flow of a program.
With the advent of multiprocessor machines, instead of just appearing to run in parallel, threads allowed the programmer to actually do two things at one time. Suddenly, a multithreaded application was inherently better than a single-threaded application largely because it was seen as more scalable than a single-threaded application.