RFR: 8323782: Race: Thread::interrupt vs. AbstractInterruptibleChannel.begin [v2]

[David Holmes]

On Thu, 18 Jan 2024 09:21:24 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> It is really safe/correct to move this outside the synchronized block? I know things have changed a bit with loom but we've "always" held a lock when doing the actual interrupt. I'd have to check the VM logic to be sure it can be called concurrently from multiple threads for the same target thread.
>> 
>> This hasn't changed. The interruptLock is used to coordinate the add/remove of the nioBlocker. When there is no nioBlocker set then the interrupt status and unparking (as in JavaThread::interrupt) has always executed without the interruptLock (named "blockerLock" in the past).
>
> I think that interrupting is just asynchronous to some extent.
> E.g. a thread polls its interrupt status clearing it thereby (without lock) before calling nio. A concurrent interrupt can be lost then even if the lock is acquired.
> (Maybe clearing should not be done by a public method)

Yep my bad on the VM side of things - no change there. But in the nioBlocker case doesn't this inherently make things more racy? Now maybe those races are allowed, but this might lead to a change in behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17444#discussion_r1458188281