Race condition in acquireLock

[nicktindall]

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.

Java-Thread-Affinity/affinity/src/main/java/net/openhft/affinity/LockInventory.java

Lines 109 to 112 in ac876e3

	if (required.canReserve(true) && anyStrategyMatches(cpuId, cpuId, strategies)) {
	updateLockForCurrentThread(bind, required, false);
	return required;
	}

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:

Java-Thread-Affinity/affinity/src/main/java/net/openhft/affinity/LockCheck.java

Lines 112 to 121 in ac876e3

	static void updateCpu(int cpu) {
	if (!canOSSupportOperation())
	return;
	try {
	replacePid(cpu, getPID());
	} catch (IOException e) {
	LOGGER.warn("Failed to update lock file for cpu " + cpu, e);
	e.printStackTrace();
	}
	}

Meaning you end up with multiple threads locked to a single core. The check and lock should be atomic, that will prevent this scenario.

[hft-team-city]

Released in Java-Thread-Affinity-3.21ea81, BOM-2.22ea49