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

Vitaly Davidovich vitalyd at gmail.com
Wed Apr 17 13:11:17 EDT 2013

What exactly are you doing in ThinkTime?
On Apr 17, 2013 9:41 AM, "Mudit Verma" <mudit.f2004912 at gmail.com> wrote:

> 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?
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/321f7192/attachment.html>

More information about the Concurrency-interest mailing list