• 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

java.util.concurrent and performance

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been trying to understand some of the new features of java.util.concurrent and I'm getting somewhat confused.

I created a basic class to represent a bank account, with simple methods to check the balance and withdraw. I then wrote three test classes. Each class ran ten threads sharing a common account; each thread would check the balance and, if it was greater than zero it would withdraw 1. When the balance reaches zero the test ends.

Test 1) No synchronization. Inevitably the account goes overdrawn.
Test 2) Wrapping the get balance and withdraw commands inside a synchronized(account) { ... } block
Test 3) As above, using the ReentrantLock class instead of synchronized.

Q1) Test 1 takes anything from 10% up to 100% longer to run than tests 2 or 3. It's very inconsistent - why might that be?

Q2) Test 2 is typically 10% quicker than Test 3. Why? I thought the idea was that the ReentrantLock was supposed to be quicker/lighter than a synchronized block?

Source code available on request. Written and tested using NetBeans 4.1 and HotSpot 1.5.0_04-b05 under Windows XP on an Athlon.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Tong:
I thought the idea was that the ReentrantLock was supposed to be quicker/lighter than a synchronized block?



Where do you get this from? The JavaDoc just seems to suggest that it simply provides enhanced functionality...
 
Dave Tong
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


Where do you get this from? The JavaDoc just seems to suggest that it simply provides enhanced functionality...



From this presentation at JavaOne.
They quoted benchmark figures that IIRC implied an 8X improvement by using the ReentrantLock.

They quoted even greater performance figures by using an AtomicInteger but so far I've not been able to reproduce that either.
[ July 07, 2005: Message edited by: Dave Tong ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Tong:
They quoted benchmark figures that IIRC implied an 8X improvement by using the ReentrantLock.

They quoted even greater performance figures by using an AtomicInteger but so far I've not been able to reproduce that either.



Without knowing more about the benchmarks, I'd assume that it only shows that you get an performance improvement *regarding these specific usage patterns*. Obviously it's not possible to deduce a performance advantage in the general case.
 
reply
    Bookmark Topic Watch Topic
  • New Topic