aspose file tools*
The moose likes Features new in Java 7 and the fly likes For Benjamin J. Evans and Martijn Verburg: On concurrency in Java 7. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "For Benjamin J. Evans and Martijn Verburg: On concurrency in Java 7." Watch "For Benjamin J. Evans and Martijn Verburg: On concurrency in Java 7." New topic
Author

For Benjamin J. Evans and Martijn Verburg: On concurrency in Java 7.

charlsy chuks
Ranch Hand

Joined: May 18, 2012
Posts: 79
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?

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?

Thanks for your answers.
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

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.

Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
charlsy chuks
Ranch Hand

Joined: May 18, 2012
Posts: 79
Thanks for the clarification. Threads is the way to go!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: For Benjamin J. Evans and Martijn Verburg: On concurrency in Java 7.