DefaultPromise's await is have lower performance than jdk's FutureTask

[liyiwen3]

much thread call await when the DefaultPromise is not done, once DefaultPromise is setted done, then the threads wait in await just wake one by one;while in same situation in the jdk's FutureTask the threads can wake at the same time.why not draw lessons from jdk’s FutureTask

[NiteshKant]

I will convert this to a discussion as it does not look like an issue, just a question.

[chrisvest]

This isn't an easy thing to do because of the complicated behaviours we need from DefaultPromise.
We use notifyAll, so all waiting threads are actually woken up at the same time, but they have to acquire the monitor lock in order to check their wait-conditions as soon as they start running again, and this means if there are multiple waiting threads, they will queue on the monitor lock.
I wouldn't expect it to be a big deal if there's only one thread waiting, though the waker and awaking threads will compete on the monitor lock to either notify the promise listeners or check the promise result, respectively.
I made an attempt to improve it a bit in #11799.

@liyiwen3 Do you have a JMH benchmark demonstrating the problem?

[liyiwen3]

suggest use CountDownLatch rather than Object's wait

[chrisvest]

I don't think it makes sense to optimise this. Blocking methods should mostly have few threads accessing the locks, and with the uncancellable state, it is quite complicated to implement this without locking.

[liyiwen3]

yes,almost makes no sense in the real situation that there are only one waiter.