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

[Bela Ban (JIRA)]

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