• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
charlsy chuks
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the clarification. Threads is the way to go!
 
reply
    Bookmark Topic Watch Topic
  • New Topic