[concurrency-interest] ConcurrentHashMap-Very Strange behavior of ReentrantLock under contention.

Mudit Verma mudit.f2004912 at gmail.com
Wed Apr 17 09:31:51 EDT 2013


Hi All,

I recently performed a scalability test (very aggressive and may be not
practical, anyhow) on put operation of ConcurrentHashMap.

Test: Each thread is trying to put (Same Key, Random Value) in HashMap in a
tight loop. Therefore, all the threads will hit the same location on
hashMap and will cause contention.

What is more surprising is, when each thread continue to do another put one
after the other, avg time taken in one put operation is lesser than when a
thread do some other work between two put operations.

We continue to see the increase in per operation time by increasing the
work done in between.  This is very counter intuitive. Only after a work of
about 10,000 - 20,000 cycles in between, per op time comes down.

When I read the code, I found out that put op first try to use CAS to
aquire the lock(64 times on multicore), only if it could not acquire the
lock on segment through CASing, it goes for ReentrantLocking (which suspend
threads .. ).

We also tweaked, the number of times CAS (from 0 to 10,000) is used before
actually going for ReentrantLocking.   Attached is the graph.

One interesting thing to note. As we increase the work between two ops,
locking with 0 CAS (pure ReentrantLocking) seems to be worst affected with
the spike. Therefore, I assume that, spike comes from ReentractLocking even
when there is a mixture of two (CAS+Lock).

Code Skeleton: For each Thread

While() {
  hashMap.put(K,randomValue);     // K is same for each thread
  ThinkTime();    < Ranging from 0 Cycles to 1 million Cycles>

}

 Machine: 48 core NUMA
Threads used:  32 (each one is pinned to a core).
#ops: In total 51200000 (each thread with 160000 ops)

That's like saying, if I do something else in between my operations (upto a
limit), contention will increase.  Very strange.

Does anyone of you know why is it happening?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/b6b7b033/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ConcurrentHashMap-Put.JPG
Type: image/jpeg
Size: 59331 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/b6b7b033/attachment-0001.jpe>


More information about the Concurrency-interest mailing list