Thanks @akarnokd, I've updated with those fixes and rebased.

A quick question about synchronized blocks vs using volatile variables in general. It would also be possible to atomically change a pair like busy and missed using an immutable wrapping object BusyAndMissed and storing it in an AtomicReference<BusyAndMissed> and use spinning to modify. It could involve some GC pressure if rapidly changing of course. Have you any experience of advantages/disadvantages with this approach?

That approach is wasteful. You only need an AtomicInteger and its increment/decrement methods. 0 means not busy, 1+ means busy and 2+ means there is still work to be done. The pair of booleans + synchronized, however, plays into the hands of lock elision and biased locking which affects our benchmarks. If it were up to me, I'd use atomics everywhere so we avoid the chance of unnecessary thread suspension due to a lock not available around 2 bytes.

Thanks, quite right for that pair of objects, was probably a bad example. So under circumstances where we are getting significant lock elision and biased locking is it also the case that the volatile read and write of terminalNotification is just like a non-volatile read and write? I left it as non-volatile to favour lock elision and biased locking in the first place.

That is a terminal event that happens once, but when the lock optimizations don't happen, you may get a hefty delay. Paying a few dozen nanoseconds for a single volatile write is way better.

Makes sense, thanks.

Thanks!