This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I would like to know whether Java's new fork/join parallel processing functionality is meant to replace Java multithreading, or, rather, supplement it.
I ask because somewhere I read a statement to the effect that functional languages (Haskell, Clojure) represent a more 'reliable' way to achieve the benefits of multithreading than concurrent multithreading itself.
I can at least partially understand this reasoning if it is in fact correct: why not divide into many processes what would have been divided into threads if common resources might be controlled by the process that forks and joins others?
But I could also understand how multithreading might be done on EACH parallel process. By this thinking the result of using fork/join functionality in combination with multithreading would be a multitude of multi-threaded processes.
So, at least in practice, are the two meant, or enabled, to be combined? or does fork/join functionality in Java 1.7 effectively replace concurrency and multithreading in Java?
Any perspective are greatly appreciated! Thanks in advance.
fork/join would not replace multi threading, it s just another added advantage. the functional languages are trying to provide distributed features which is better than concurrent, but those are not yet become standards. One who what to implement multi threading features still could use concurrent package.
Java's basic multi-threading , with Thread, wait etc is simply the lowest level. Higher levels are built on it -- all the libraries in java.util.concurrent, and others. Fork/Join is just one example of what can be built using the lowlevel primitives. In most cases, you indeed do want to use the higher level libraries.