Java Reference
In-Depth Information
ing to the semantics of the machine language, and interacting with the outside world via the
operating system through a set of I/O primitives. For each instruction executed there was
a clearly defined “next instruction”, and control flowed through the program according to
the rules of the instruction set. Nearly all widely used programming languages today follow
this sequential programming model, where the language specification clearly defines “what
comes next” after a given action is executed.
The sequential programming model is intuitive and natural, as it models the way humans
work: do one thing at a time, in sequence—mostly. Get out of bed, put on your bathrobe, go
downstairs and start the tea. As in programming languages, each of these real-world actions
is an abstraction for a sequence of finer-grained actions—open the cupboard, select a flavor
of tea, measure some tea into the pot, see if there's enough water in the teakettle, if not put
some more water in, set it on the stove, turn the stove on, wait for the water to boil, and so on.
This last step—waiting for the water to boil—also involves a degree of asynchrony . While
the water is heating, you have a choice of what to do—just wait, or do other tasks in that
time such as starting the toast (another asynchronous task) or fetching the newspaper, while
remaining aware that your attention will soon be needed by the teakettle. The manufacturers
of teakettles and toasters know their products are often used in an asynchronous manner, so
they raise an audible signal when they complete their task. Finding the right balance of se-
quentiality and asynchrony is often a characteristic of efficient people—and the same is true
of programs.
The same concerns (resource utilization, fairness, and convenience) that motivated the de-
velopment of processes also motivated the development of threads . Threads allow multiple
streams of program control flow to coexist within a process. They share process-wide re-
sources such as memory and file handles, but each thread has its own program counter, stack,
and local variables. Threads also provide a natural decomposition for exploiting hardware
parallelism on multiprocessor systems; multiple threads within the same program can be
scheduled simultaneously on multiple CPUs.
Threads are sometimes called lightweight processes , and most modern operating systems
treat threads, not processes, as the basic units of scheduling. In the absence of explicit co-
ordination, threads execute simultaneously and asynchronously with respect to one another.
Since threads share the memory address space of their owning process, all threads within a
process have access to the same variables and allocate objects from the same heap, which
allows finer-grained data sharing than inter-process mechanisms. But without explicit syn-
chronization to coordinate access to shared data, a thread may modify variables that another
thread is in the middle of using, with unpredictable results.
Search WWH ::




Custom Search