Java Reference
In-Depth Information
Chapter 1.
Introduction
Writing correct programs is hard; writing correct concurrent programs is harder. There are
simply more things that can go wrong in a concurrent program than in a sequential one. So,
why do we bother with concurrency? Threads are an inescapable feature of the Java language,
and they can simplify the development of complex systems by turning complicated asynchron-
ous code into simpler straight-line code. In addition, threads are the easiest way to tap the com-
puting power of multiprocessor systems. And, as processor counts increase, exploiting con-
currency effectively will only become more important.
1.1. A (Very) Brief History of Concurrency
In the ancient past, computers didn't have operating systems; they executed a single program
from beginning to end, and that program had direct access to all the resources of the machine.
Not only was it difficult to write programs that ran on the bare metal, but running only a single
program at a time was an inefficient use of expensive and scarce computer resources.
Operating systems evolved to allow more than one program to run at once, running individual
programs in
processes
: isolated, independently executing programs to which the operating sys-
tem allocates resources such as memory, file handles, and security credentials. If they needed
to, processes could communicate with one another through a variety of coarse-grained com-
munication mechanisms: sockets, signal handlers, shared memory, semaphores, and files.
Several motivating factors led to the development of operating systems that allowed multiple
programs to execute simultaneously:
Resource utilization.
Programs sometimes have to wait for external operations such as in-
put or output, and while waiting can do no useful work. It is more efficient to use that
wait time to let another program run.
Fairness.
Multiple users and programs may have equal claims on the machine's resources.
It is preferable to let them share the computer via finer-grained time slicing than to let
one program run to completion and then start another.
Convenience.
It is often easier or more desirable to write several programs that each per-
form a single task and have them coordinate with each other as necessary than to write
a single program that performs all the tasks.
In early timesharing systems, each process was a virtual von Neumann computer; it had a
memory space storing both instructions and data, executing instructions sequentially accord-
