[jboss-jira] [JBoss JIRA] Commented: (JGRP-387) Reduce heavily contented locks

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-387?page=comments#action_12356570 ] 
            
Bela Ban commented on JGRP-387:
-------------------------------

replaced NAKACK.received_msgs with ConcurrentHashmap, removed synchronization 

> Reduce heavily contented locks
> ------------------------------
>
>                 Key: JGRP-387
>                 URL: http://jira.jboss.com/jira/browse/JGRP-387
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> Identify and reduce/eliminate heavily contended locks, e.g. 
> NakReceiverWindow: 
> N threads will messages from the same receiver will hit the NRW (synchronization on NRW for inserts and removes). We can possibly replace the sorted hashmaps in NRW with their java.util.concurrent equivalents, so access is distributed across bucket (lock striping), reducing heavily contended locks. Also, replace ReentrantLock (e.g. used in add() and remove()) with the j.u.c.lock equivalent.
> NAKACK:
> Same as above: replace received_msgs with ConcurrentHashMap. Use equivalents from j.u.c.lock to replace the locks used.
> Another big source of contention is that multiple threads with messsages from the *same* receiver will all add their message to the *same* NRW, then *only one* thread will remove them all and pass them up, causing the other threads to block (incurring context switches and possible processor cache flushes). When the delivery thread returns, all other threads wake up and all of them return after NRW.remove() returns null !

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira