Java Reference
In-Depth Information
Concurrent programming has always been difficult, and has usually been left to the low-level
system wizards who can then provide a sequential view of the world to the average program-
mer. Java, however, was originally intended to be used in systems where a high degree of con-
currency was the only way to get acceptable performance. As such, it has language constructs
that can be used to build reliable concurrent programs. By utilizing these constructs correctly,
you can take advantage of new advances in chip design. Even if you don't write highly con-
current code yourself, you should try to write any classes that are designed to be reused so
that they are safe when used with highly concurrent code, which requires some understanding
of the Java concurrency constructs. That Java has such constructs is a good thing, especially
given current hardware trends. But it takes great care and thought to use these constructs cor-
rectly. So I will end this discussion of the good parts of Java proper with a gentle introduction
to concurrency in the Java environment.
If nothing else, you should be aware of just how hard it is to handle concurrency correctly.
This will give you more reason not to write your own multithreaded classes, instead using
those that have already been written, debugged, and optimized when you can. The Java col-
lections have a set of concurrency-safe implementations, and you should always use those in
favor of any you may write yourself. You should also make sure that you read the document-
ation for classes to find out whether they are safe in a multithreaded environment, and make
sure that you don't use classes that aren't safe as though they were. Finally, you should make
sure that your own documentation is clear about whether multithreaded code can safely use
your implementations.
Enough with the warnings: back to looking at how to use multiple threads of control in your
Java programs.
We've already seen one way in which you could do this. If you can break your larger program
up into a set of separate, smaller programs that communicate with Remote Method Invoca-
tion, you could make use of multiple cores by running the different programs together. This
assumes that you are actually getting parallelism when you do this rather than just running
work just fine.
A more powerful approach tries to achieve currency in a single Java Virtual Machine by using
multiple threads in that VM. Threads, unlike processes, can share the same address space,
so they are able to communicate and coordinate through accessing the same memory. This
can make inter-thread communication much faster than what you can achieve using RMI.
However, this also means that the two threads can interfere with each other by trying to do
different things to the same place in memory at the same time. The trick in concurrent pro-
