RFR: 8257831: Suspend with handshakes [v2]

[Richard Reingruber]

On Wed, 7 Apr 2021 06:51:22 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> But I still think we can just call is_suspended() here. If is_suspended() returns false, then Z hasn't finished suspending A yet (either async operation was still not added to the queue in case this is the first suspend for A, or do_handshake() hasn't yet finished for that SuspendThreadHandshake operation in case there was already an async operation in the queue). Since we have already acquired OM, then Z will not see that after being suspended A switched from not owning OM to owning it. It will always see that A owned OM. And A will still block for the suspension in the 'else' clause since poll is armed due to SuspendThreadHandshake operation(even if async operation was still not added to the queue at the time A called is_suspended()), but we wouldn't need to release OM.
>> If is_suspended() returns true then at most we will have a false positive, since it could be that after the check somebody already resumed A, but that can also happen even with suspend_request_pending() right after releasing HandshakeState::_lock.
>> Is that correct or am I missing something?
>
> I'm not saying it doesn't work, I'm saying it works by accident (I never intended to be able to read the flag without HandshakeState lock).
> So yes, if the flag is false (lockless read), it is not possible for the suspend to have happened before we locked the OM.
> And once poll is armed for the synchrone handshake it will stay armed until after we executed the asynchrone handshake trap.
> 
> What is possible is that we have armed for the suspend but not yet set the flag.
> If we consider the flag as the tipping point and not the start of execution of the suspend sync handshake, we can do the lockless read.

> But I still think we can just call is_suspended() here

@pchilano, potentially I had similar thoughts when I asked about it before the long weekend: the current thread will suspend either way in the then or else block if the execution of the SuspendThreadHandshake was started while the current thread was _thread_blocked. If the suspend is ordered with operations on OM then is_suspended() will return true. Otherwise it is ok to become the owner. This is a more intuitive reasoning. I prefer yours.

While looking at this I noticed that suspending in L428 could be problematic because the OM is just entered half way.

Maybe we could use plain ThreadBlockInVM and deal with unlocking the OM very late just before waiting in HandshakeState::suspend_in_handshake().

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

PR: https://git.openjdk.java.net/jdk/pull/3191