DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Parallel Framework Shootout

Parallel Framework Shootout

Cedric Beust user avatar by
Cedric Beust
·
Jan. 17, 11 · Java Zone · Interview
Like (0)
Save
Tweet
4.46K Views

Join the DZone community and get the full member experience.

Join For Free

The JVM concurrent (or parallel, I’m using these terms interchangeably although I’m aware they have subtly different meanings) worlds has been exploding with activity and innovations lately. It all started with the now veteran but extremely well designed java.util.concurrent package and more recently, we have seen Scala enter the fray with its Actor Model, Groovy with GPars and Doug Lea’s Fork Join Framework (PDF). Let me know if I forgot any.

I find all these frameworks intellectually interesting but I’m still not quite convinced that either of the incumbents is superior to java.util.concurrent (although if I had to pick one, it would probably be GPars). Interestingly, all these frameworks intend to simplify concurrent programming but a lot of these claims are going pretty much unchallenged, or supported by trivial exercises that are biased toward the framework’s own documentation.

I’m keeping my mind open but so far, I haven’t seen any blinding proof of either of these superiority claims. What I would really like to see is a non-trivial (i.e. requiring a few hundreds of lines of code to solve) concurrent problem written with java.util.concurrent and other parallel frameworks and a tentatively objective analysis of the pros and cons of each approach, on several axes: maintainability, testability, readability (more subjective), debuggability, performance, reliability, etc…

My gut feeling is telling me that while the Actor/Immutable/lock free model appears simpler, it also introduces a radical shift in the way you implement your solution that might be detrimental to its maintenance on the long run. At the end, you might end up with a simple locking model (since there are no locks) but at the expense of a more spaghetti-ish structure, since all these actors are now sending asynchronous messages to each other and retracing and debugging such a flow can be challenging.

Another gut feeling that I haven’t been able to shake off is the fact that the actor model introduces a single locking choke point (the inbox queue) while Java’s traditional locking approach allows you to position your lock wherever you want, and over an arbitrarily large (or small) portion of code. Determining such a locking can be challenging, but once you’ve solved that particular problem, it’s hard for me to imagine that there are more optimal ways of solving this problem.

I’m pretty optimistic about GPars because it’s built on top of java.util.concurrent while offering Groovy’s more compact syntax, which has the benefit of being simpler while very accessible for Java programmers.

The first step would be to come up with a non trivial problem that is a good match for a parallel implementation… Any suggestions?

Update: here is a timely discussion about someone expressing the difficulty they’re having switching to an asynchronous mindset.

 

From http://beust.com/weblog/2011/01/13/parallel-framework-shoot-out/

Framework

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Translate Value to Executives Using an Outcome-Driven Mindset
  • SQL Database Schema: Beginner’s Guide (With Examples)
  • 5 Myths of Kubernetes
  • Migrating Legacy Applications and Services to Low Code

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo