[jboss-jira] [JBoss JIRA] Commented: (JGRP-1085) NakReceiverWindow: possibly replace ReadWriteLock

[ https://jira.jboss.org/jira/browse/JGRP-1085?page=com.atlassian.jira.plug... ] Bela Ban commented on JGRP-1085: -------------------------------- For example, in NakReceiverWindow.add(), we can de-scope it like this: void add(seqno, msg) { lock: if(seqno == current): action=PUT if(seqno < current): return if(seqno > current): action=PUT_AND_XMIT else action=PUT_IF_ABSENT end-lock: switch(action): case PUT: xmit_table.put(seqno, msg) case PUT_AND_XMIT: xmit_table.put(seqn,msg) / retransmitter.put(seqno) case PUT_IF_ABSENT: if xmit_table.putIfAbsent(seqn, msg) --> retransmitter.remove(seqno) } The work inside the lock scope is only to determine what to do with the message, the real (and costly) work is done *outside* the scope, so we can have more concurrent add() invocations. Same for NakReceiverWindow.removeMany(): - Determine in the lock scope how many messages we can remove (add them to a list and add the seqnos of messages to be discarded from the xmit_table to a different list. - After the lock-scope: remove all seqnos from xmit_table (if any) and return list TODO: write a test which only uses NakReceiverWindow and measures how long it takes to insert 1 million messages. With the changes above, this should be faster ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira