If I understand correctly, you're using the CountDownLatch here to avoid both a data race and a race condition, and the l.await() call will indeed prevent both of them.

However, l.await() is a blocking call, and it could potentially cause a deadlock if the thread pool runs out of threads. You could mitigate that by using a blocking block, to signal to the thread pool that it should create more threads, but it's not exactly the most efficient solution (and you'd be relying on the ExecutorService to do the right thing).

Btw, I say above both a data race and a race condition because:

• The moment you've shared firstCompleteHandler with a future with onCompleteDereg, it becomes possible that another thread will concurrently invoke firstCompleteHandler, and consequently invoke foreach on deregs.
  At the same time, the remainder of this loop is mutating deregs.
  Since ListBuffer is not a thread-safe class, there is no guarantee that the foreach call will traverse all the entries that are in a concurrently modified ListBuffer - i.e. without the latch, there would be a data-race here.

• But, in addition to that, even if the thread-safety (i.e. data-race problem) were resolved by using some thread-safe collection, there is no guarantee that this loop will complete by the time some other thread invokes firstCompleteHandler. That is, without a latch, there would be a race-condition here.

Here is an alternative suggestion that would avoid all three problems (data race, race condition and the blocking).

You could be to store an immutable list (i.e. List) of deregistration handlers into a single atomic reference (deregsRef of type AtomicReference[List[() => Unit]]), and have a protocol in which:

• a non-null value in the ref means that no future completed yet, i.e. no future took the responsibility to do the registrations
• and a null value means that some future (which in fact completed first) took over the responsibility to call the deregistration handlers

Concretely:

1. In the while loop, each iteration should:

val oldDeregs = deregsRef.get()
if (oldDeregs == null) {
  break
}
val newDeregs = (i.next().onCompleteDereg(firstCompleteHandler) :: oldDeregs
if (!deregsRef.compareAndSet(oldDeregs, newDeregs) {
  // Update failed, meaning that there is a null in deregsRef
  // you could do: assert(deregsRef.get() == null)
  
  // You need to call the last deregistration handler, because it was not added to the list
  newDeregs.head.apply()
  // Then, break.
  break
}

2. In the firstCompletedOf:

val r = getAndSet(null)
if (r ne null) {
  while (true) {
    val deregs = deregsRef.get()
    if (deregsRef.compareAndSet(deregs, null)) {
      // Now, it's your responsibility to do the deregistrations.
      deregs.foreach(_.apply())
      break
    }
  }
}

In fact, you could simplify this further if you wanted, by keeping a single AtomicReference, but changing its type so that it holds both the promise and the thus-far created deregistration callbacks. I.e., in this line, declare this:

new AtomicReference[(Promise[T], () => Unit)](p) with (Try[T] => Unit) {

And then adjust the code after getAndSet accordingly.

Thank you Alex :) I was trying to find a solution along the lines you suggest but missed a few ideas. At least I managed to spot the races, that's why I ended up using a CountDownLatch.

Now I think it looks good. It seems we can keep only the list of deregistration functions in the AtomicReference, the promise can be referenced by closure. Would be great if you can take another look.