The JavaWorld article looks at the process of taking a single threaded algorithm and converting it to be multi-threaded. The basic approach is outlined as:
- Develop a single-threaded, sequential, robust, and clearly organized version of your algorithm. If you're reading this article to speed up something that exists, you may already have this step covered.
- Identify the subtasks. Examine the algorithm to identify the discrete stages. This shouldn't be difficult if you performed Step 1 adequately. Each subtask probably has its own method, or at least a clearly-delineated block of code. If you have difficulty identifying the subtasks, you probably need to understand the algorithm better or reorganize your code. In that case, return to Step 1.
- Benchmark the algorithm. In other words, time the identified subtasks to determine the fraction of time consumed by each. This should be a trivial matter of adding some timing and output statements.
- Delegate the most time-consuming subtasks to a thread pool. Now we come to the most difficult part: reorganizing your code so the slowest subtasks are performed concurrently by multiple subtask threads. Luckily, two utility classes in java.util.concurrent greatly simplify the process.
The article then continues by taking a K-Means algorithm and multi-threading it using java.util.concurrent API features such as ThreadPoolExecutor and CyclicBarrier.
A TSS discussion on this article generated a number of interesting comments of multi-threading in respect to JEE.
...First of all, most J2EE applications are heavy transaction based applications. At least the ones that I work on in the financial industry. Because of the J2EE specification, you can't be spawning threads. You also can't have multiple threads accessing the same transaction. It just doesn't work.A way of breaking up large chunks of work into smaller managable is to use JMS to leverage the container to do the multi-threading for you. But once again, you have to take into account the transactions and keep track of those chunks of work in different transactions.
J2EE applications already take advantage of multi-core, multiple CPUs already. Every applications server uses some sort of multiple threads, weather that is in an execute queue or (gasp) spawning a new thread for each connection.
Billy Newport responds:
...I beg to differ. If only the simple threading models offered by typical containers were adequate for the diversity of applications out there. I added the WorkManager spec to WebSphere and then standardized it using the commonj APIs for exactly this purpose. There are clever people out there who can be trusted to write threaded code and commonj lets them build J2EE applications using a threading model thats appropriate for the application rather than the boiler plate models provided by the vendors. Yes, JMS can be used as a way to do it also but it's millions of times slower than native threading...
This comment is followed by a blog post on why multi-core may actually be bad for Java. Among the items he notes:
- Java likely has a longer path length than languages like C and clock speeds won't help with this.
- JavaEE promotes a simple threading model for applications
- Garbage collection remains heavily dependant on clock speed for small pauses.