Multithreading is not a new concept in software, but it is new to come into the limelight. People have been kicking around experimental implementations for 20 years or more, but it is only in the last few years that desktop hardware (especially desktop multiprocessors) became powerful enough to make multithreading popular.
There is a POSIX[1] document 1003.4a (ratified June 1995) that describes a threads API standard. The threads described by the POSIX model and the threads available in Java do not completely coincide. The Java designers didn't use POSIX threads because the POSIX model was still under development when they implemented Java. Java threads are simpler, take care of their own memory management, and do not have the full generality (or overhead) of POSIX threads.
A computer system can give the impression of doing several things simultaneously, like print from one window, compile in another, while downloading music in a third. The OS runs each process for a few milliseconds, then saves the process state, switches to the next process, and so on. Threads simply extend that concept from switching between several different programs to switching between several different functions executing simultaneously within a single program, as shown in Figure 13-1.
A thread isn't restricted just to one method. Any thread in a multithreaded program can call any series of methods that could be called in a single-threaded program. You often have one thread that waits for input from a GUI and another thread that processes the input when it arrives.
When the operating system switches from running one process to running another for its time slice, there is a somewhat costly overhead of saving all program state (virtual memory contents and map, file descriptors, interrupt settings, etc.). When the JVM switches from running one of your threads to running another of your threads, the cost is much lower. The context switch takes place within the same address space, so the JVM just saves a few registers, changes the stack pointer and the program counter, and the next thread is ready to go. Threads can actually achieve the counterintuitive result of making a program run faster, even on uniprocessor hardware. This occurs when there are calculation steps that no longer have to wait for earlier output to complete, but can run while the I/O is taking place.
Threads (an abbreviation of “threads of control,” meaning control flow) are the way we get several things to happen at once in a program. Why is this a good idea? In an unthreaded program (what you have been using so far in Java, and what you have always used in Fortran, Pascal, C, Basic, C++, COBOL, and so on), only one thing happens at a time. Threads allow a program to do more than one thing at a time. There are three reasons why you would do this:
-
You can write interactive programs that never “go dead” on the user. You might have one thread controlling and responding to a GUI, while another thread carries out the tasks or computations requested, while a third thread does file I/O, all for the same program. When one part of the program is blocked waiting on some resource, the other threads can still run.
-
Some programs are easier to write if you split them into threads. The classic example is the server part of a client/server. When each request comes in from a client, it is convenient if the server can spawn a new thread to process that one request. The alternative is to have one larger server program algorithmically try to keep track of the state of each individual request.
-
Some programs are amenable to parallel processing. Writing them as threads allows the code to express this. Examples include some sorting and merging algorithms, some matrix operations, searching for aliens (à la http://seti.org), and many recursive algorithms.
[1] POSIX is an operating system standard heavily weighted to a common subset of Unix.