Although you can make a great deal of use of distributed objects without doing any MT
programming, knowing what they are doing and being able to create objects that are threaded will
increase the usefulness of the objects you do write.
Same Binary for Uniprocessors and Multiprocessors
In most older parallel processing schemes, it was necessary to tailor a program for the individual
hardware configuration. With threads, this customization isn't required because the MT paradigm
works well irrespective of the number of CPUs. A program can be compiled once, and it will run
acceptably on a uniprocessor, whereas on a multiprocessor it will just run faster.
Many programs are structured more efficiently with threads because they are inherently
concurrent. A traditional program that tries to do many different tasks is crowded with lots of
complicated code to coordinate these tasks. A threaded program can do the same tasks with much
less, far simpler code, as in Figure 2-13. Multithreaded programs can be more adaptive to
variations in user demands than single-threaded programs can.
Figure 2-13. Simplified Flow of Control in Complex Applications
This is quite some set of claims, and a bit of healthy skepticism is called for. Sure, it sounds good
when we say it, but what about when you try to use it? We cannot guarantee that you will
Search WWH :