. . .
Concurrency means that two or more threads (or traditional processes) can be in the middle of
executing code at the same time; it could be the same code or it could be different code (see
Figure 2-6). The threads may or may not actually be executing at the same time, but rather, in the
middle of it (i.e., one started executing, it was interrupted, and the other one started). Every
multitasking operating system has always had numerous concurrent processes, even though only
one could be on the CPU at any given time.
Figure 2-6. Three Threads Running Concurrently on One CPU
Parallelism means that two or more threads actually run at the same time on different CPUs (see
Figure 2-7). On a multiprocessor machine, many different threads can run in parallel. They are, of
course, also running concurrently.
Figure 2-7. Three Threads Running in Parallel on Three CPUs
The vast majority of timing and synchronization issues in multithreading (MT) are those of
concurrency, not parallelism. Indeed, the threads model was designed to avoid your ever having to
be concerned with the details of parallelism. Running an MT program on a uniprocessor (UP) does
not simplify your programming problems at all. Running on a multiprocessor (MP) doesn't
complicate them. This is a good thing.
Let us repeat this point. If your program is written correctly on a uniprocessor, it will run correctly
on a multiprocessor. The probability of running into a race condition is the same on both a UP and
an MP. If it deadlocks on one, it will deadlock on the other. (There are lots of weird little
exceptions to the probability part, but you'd have to try hard to make them appear.) There is a
small set of bugs, however, which may cause a program to run as (naively) expected on a UP, and
show its problems only on an MP (see Bus Architectures).
System Calls
A system call is basically a function that ends up trapping to routines in the kernel. These routines
may do things as simple as looking up the user ID for the owner of the current process, or as
complex as redefining the system's scheduling algorithm. For multithreaded programs, there is a
serious issue surrounding how many threads can make system calls concurrently. For some
operating systems, the answer is "one"; for others, it's "many." The most important point is that
system calls run exactly as they did before, so all your old programs continue to run as they did
before, with (almost) no degradation.
Search WWH :
Custom Search
Previous Page
Multithreaded Programming with JAVA - Topic Index
Next Page
Multithreaded Programming with JAVA - Bookmarks