When multiple processes are attempting to acquire the same lock, the check to see if the core can be reserved (canReserve) and the subsequent locking of the core (updateLockForCurrentThread) are done as two separate steps.
The locking of the core logs and swallows exceptions thrown in the process of locking, meaning if two threads pass the canReserve check, while it's reservable they will both go on to "lock" the core:
When multiple processes are attempting to acquire the same lock, the check to see if the core can be reserved (
canReserve
) and the subsequent locking of the core (updateLockForCurrentThread
) are done as two separate steps.https://github.com/OpenHFT/Java-Thread-Affinity/blob/ac876e3647665acb266c19f775274c92dcd0e079/affinity/src/main/java/net/openhft/affinity/LockInventory.java#L109-L112
The locking of the core logs and swallows exceptions thrown in the process of locking, meaning if two threads pass the
canReserve
check, while it's reservable they will both go on to "lock" the core:https://github.com/OpenHFT/Java-Thread-Affinity/blob/ac876e3647665acb266c19f775274c92dcd0e079/affinity/src/main/java/net/openhft/affinity/LockCheck.java#L112-L121
Meaning you end up with multiple threads locked to a single core. The check and lock should be atomic, that will prevent this scenario.