Confusing startLock.wait()/finishLock.wait() calls in WindowsSelectorImpl

[Alan Bateman]

Moving this to nio-dev. I don't disagree that the locking is hard to 
follow but note that this Selector implementation has not been used (by 
default) for a few releases. It may eventually be deleted but we 
continue to build/include it until there is more confident in the newer 
implementation.

-Alan

On 20/03/2022 20:53, Andrey Turbanov wrote:
> Hello.
> I found confusing calls to Object.wait() in 2 methods:
> 1. sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart
> https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L252
> 2. sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads
> https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L304
>
> Methods 'sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads'
> and 'sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart'
> are synchronized. It means they are synchronized on 'this'.
> But, somewhy, this methods calls to 'wait()' via reference fields in
> outer class:
>
> private synchronized boolean waitForStart(SelectThread thread) {
>     ...
>    startLock.wait();
>
> private synchronized void waitForHelperThreads() {
>     ...
>    finishLock.wait();
>
>
> It seems confusing to me. I would expect that method 'wait()' to be
> called directly on 'this' too.
> For StartLock it even allows to mark it as a 'static' nested class
> (minus one redundant field).
> Is it intentional to call 'wait()' like this?
>
>
> Andrey Turbanov