charlsy chuks wrote:Hi ,
I must quickly admit that you guys did a good job in giving an expose on Concurrency in Java after I read a bit about threads as Pre Java 5 had it and how it obtains henceforth in your sample chapter.
The subject of threading always interests me because I think its an awful waste of time if a heavy weight program cannot be split into threads and assigned to different threads in a process. Divide and Conquer still rocks any time any day!
1. However, would you say the complexity of threading arises from the 'Design Forces' contradicting each other or from the way the util.concurrent API handles the low level aspect of Threads as it interacts directly with the cores in a multiple core CPU?
Good question! It's to do with both. The design forces are inherent in any concurrency work, regardless of language. It's what makes designing good threading models and APIs around concurrency so difficult. The fairly low level
Thread representation that Java has was pretty good for its time but is probably only adequate for today's world, which is why you see APIs like hte Fork and Join framework being built on top or even a 3rd part lib such as the Actors based Akka library.
Java isn't going to be getting rid of Thread anytime soon, so it will be interesting to see if the APIs can be altered in such a way that they're heavily abstracted from. Java 8 collections are certainly looking good on that front.
charlsy chuks wrote:
2. How can we ensure there is a balance or compromise whenever we decide to incorporate these Design Forces into our code and still deliver efficient multi-threaded systems?
You measure! Set the thresholds of the performance you want to see (say "Sort this 1,000,000 element array in 3 seconds with _no_ errors") and experiment with the various implementations.