experience the same wonderful results, but we can point out a number of cases where other folks
have found MT programming to be of great advantage (see Performance).
What Kinds of Programs to Thread
There is a spectrum of programs that one might wish to thread. On one end, there are those that
are inherently "MT-ish"--you look at the work to be done, and you think of it as several
independent tasks. In the middle, there are programs where the division of work isn't obvious, but
possible. On the far other end, there are those that cannot reasonably be threaded at all.
Inherently MT Programs
Inherently MT programs are those that are easily expressed as numerous threads doing numerous
things. Such programs are easier to write using threads, because they are doing different things
concurrently anyway. They are generally simpler to write and understand when threaded, easier to
maintain, and more robust. The fact that they may run faster is a mere pleasant side effect. For
these programs, the general rule is that the more complex the application, the greater the value of
Typical programs that are inherently MT include:
Independent tasks
A debugger needs to run and monitor a program, keep its GUI active, and display an interactive
data inspector, dynamic call grapher, and performance monitor--all in the same address space, all
at the same time.
A server needs to handle numerous overlapping requests simultaneously. NFSŪ, NIS, DBMSs,
stock quotation servers, etc., all receive large numbers of requests that require the server to do
some I/O, then process the results and return answers. Completing one request at a time would be
very slow.
Repetitive tasks
A simulator needs to simulate the interactions of numerous different elements that operate
simultaneously. CAD, structural analysis, weather prediction, etc., all model tiny pieces first, then
combine the results to produce an overall picture.
Not Obviously MT Programs
Not obviously MT programs are those not inherently MT but for which threading is reasonable.
Here you impose threads upon an algorithm that does not have an obvious decomposition, in order
to achieve a speedup on an MP machine. Such a program is somewhat harder to write, a bit more
difficult to maintain, etc., than its nonthreaded counterpart, but it runs faster. Because of these
drawbacks, the (portions of) programs chosen are generally quite simple.
Typical programs in this class include:
Numerical programs
Search WWH :
Custom Search
Previous Page
Multithreaded Programming with JAVA - Topic Index
Next Page
Multithreaded Programming with JAVA - Bookmarks