On Thu, 18 Jan 2024 09:21:24 GMT, Richard Reingruber <rr...@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
