[concurrency-interest] RentrantLock performance vs. AtomicInt
dl at cs.oswego.edu
Sat Feb 4 16:36:27 EST 2006
> My micro benchmark isn't as sophisticated as the IBM's, it simply
> computes the sum of 10,000,000 by incrementing an integer from
> 0-10000000. I've wrote 3 variations. One is protected by a
> synchronized block, the other an AtomicInteger and AtomicLong, and
> finally a ReentrantLock. I'm having trouble groking why ReentrantLock
> is so much faster than the Atomic objects as the number of threads
> increase. I looked through the ReentrackLock source and it's built
> around similiar CAS calls as the Atomic classes, so why is it so much
It is because all but a tiny fraction of those CAS'es are failing,
and causing the memory system to slosh cache lines around. For locks,
it is better to block some of those threads, so the others can make
progress, and then allow the blocked ones to eventually make progress too.
For things other than locks, other strategies may apply. Stay tuned for
some improvements in java.util.concurrent queues etc along those lines.
BTW, In mustang, you'll find that builtin sync has performance closer
to that of ReentrantLock in programs like this due, to friendly competition
between the hotspot folks and us j.u.c folks.
More information about the Concurrency-interest