File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes java.util.concurrent and performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "java.util.concurrent and performance" Watch "java.util.concurrent and performance" New topic
Author

java.util.concurrent and performance

Dave Tong
Greenhorn

Joined: Jul 06, 2005
Posts: 10
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Dave Tong
Greenhorn

Joined: Jul 06, 2005
Posts: 10
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.util.concurrent and performance
 
Similar Threads
When to use "thread-safe" classes?
Thread question
k & b , Ryan and Monica problem......
Synchronization Issue With Threads.
Using synchronized still doesn't solve the "lost update" problem