[
https://jira.jboss.org/jira/browse/JGRP-933?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-933:
-------------------------------
Might have to deprecate eager_lock_release. This doesn't make any sense anyway with
atomic boolean vars, because there's ever only 1 thread from the same sender removing
messages. So the following scenario
- Thread1 is acquiring the lock for sender S
- Thread2 is waiting to acquire the lock for sender S
- Thread1 removes message M1 and passes it up
- Thread1 is used to send a message, so down() is invoked and the lock for sender S is
released if eager_lock_release is true
- Thread2 can remove the next message while Thread1 is still sending a message down
cannot happen, because Thread2 will CAS the atomic boolean and return if the CAS fails !
NAKACK/UNICAST: eager lock releasing not respected
--------------------------------------------------
Key: JGRP-933
URL:
https://jira.jboss.org/jira/browse/JGRP-933
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
In both NAKACK and UNICAST, we have atomic booleans, which are consulted before trying to
acquire the lock. So if a lock is released eagerly in a ProtocolStack.down() call,
although the lock is released, the atomic var isn't, and so subsequent threads will
still not be able to process different messages.
A simple solution would be to release the lock *and* the atomic var in down().
OTOH, we should see whether we can use either locks or atomic vars, but not *both*.
This will need to be redesigned anyway with scopes in place
(
https://jira.jboss.org/jira/browse/JGRP-822).
--
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