-
Feature Request
-
Resolution: Done
-
Minor
-
None
-
None
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation before acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
- relates to
-
JGRP-387 Reduce heavily contented locks
-
- Resolved
-