]
Bela Ban resolved JGRP-829.
---------------------------
Resolution: Done
Done and tested for NAKACK and UNICAST. SEQUENCER doesn't need this, as it relies on
the FIFO order of NAKAC
NAKACK: use CAS to determine whether to acquire the lock in NAKACK
------------------------------------------------------------------
Key: JGRP-829
URL:
https://jira.jboss.org/jira/browse/JGRP-829
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.7
Currently, we acquire a lock for the NakReceiverWindow for a given sender S. If we have
20 threads for S, then all will add their message to the NRW, then block on the lock. 1
thread will be acble to acquire the lock, all other 19 will block. When the other threads
are finally able to acquire the lock, they will return immediately because the first
thread already removed and processed all messages.
GOAL:
There should only be one thread for S acquiring the lock and processing the message for
S. In the above example, all 19 threads for S will return immediately without acquiring
the lock and without blocking.
SOLUTION:
Use a CAS to determine whether a thread need to acquire the NRW lock or not. If not,
return immediately. This way, a thread is available in the pool for other msgs to get
processed.
We need to make sure that a thread doesn't return when reading the CAS, and
immediately afterwards, the other (processing) thread returns, so we have *no* thread
processing the messages !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: