]
Bela Ban resolved JGRP-387.
---------------------------
Resolution: Done
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: