|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 7
In fact, we can regard the vast majority of Java EE (Java EE is Sun's new name for J2EE) systems as a simplified case of a parallelizable problem, where the average task size is small, task boundaries are well defined, and few interdependencies between the tasks are carried out in the system.
What advances can we expect to see in terms of additional software support for parallel hardware in the future?
Software engineers will be expected to have more explicit knowledge about concurrency, which will be reflected in the tools we use. Java IDEs like Eclipse, NetBeans, and IntelliJ will support refactoring code to make it more thread-friendly in the same way that I can extract an interface, fix imports, or change the scope of a variable today.
In a five-year timeframe, the core Java programming language will be extended to provide first-class, explicit support for parallel computing, in much the same way that first-class support for XML is being planned at the moment. This support will greatly enhance the power of tools to automatically suggest simple "parallel-friendly" modifications to algorithms.
This article so far has given you a basic but firm grounding in parallel computing and some of the theory behind it. Now we
move on to apply that knowledge to the design and implementation of Java-based systems (bearing in mind that I do not plan
to give a tutorial on Threads, ThreadLocal, or use of the synchronized keywords—see Resources for sources dealing with these topics).
Let's use Amdahl (the pessimist) and Gustafson (the optimist) one more time in this article to drive the next few sections:
Amdahl: "Forget about increased performance. If I were you, I'd be more worried about making sure my application simply runs at least as well on the new chips and that they don't expose some weird threading or race condition bug."
Gustafson: "Hey, the new hardware is here! Threads, threads, and more threads! It's one big thread party!"
(Actually, Gene Amdahl is a successful entrepreneur, so I doubt he is pessimistic. It's also poetic license for me to assume that Gustafson goes around shouting "It's one big thread party!" I hope both authors will forgive my using their names to create a literary construct in this article. Note to self: Consider copying Dan Brown and using biblical characters in next JavaWorld article.)
The fundamental question to ask is: Does the Java programming language and platform give developers the capability to correctly and efficiently take advantage of parallel processing hardware?
One of Java's strongest points is the java.lang.Thread class, which has been in the core JDK libraries since the 1.0 release. One of the most significant upgrades to the Java platform
in release 5 and higher is the new java.util.concurrent library. It is long overdue. (Doug Lea created and maintained his util.concurrent package for a long time before it moved into the core JDK.) Key classes to examine here are the java.util.concurrent.Executor and java.util.concurrent.Executors. There are two important points to note about this library:
Archived Discussions (Read only)