On Tue, 6 Apr 2021 12:54:40 GMT, Robbin Ehn <r...@openjdk.org> wrote:
>> The only reason _suspended is volatile is to be able to make the the fast
>> check in resume().
>> So disregard that early check and that it is volatile, the users of the flag
>> uses HandshakeState lock for synchronizing reads and stores to that flag.
>>
>> E.g
>> set_suspend(true);
>> set_async_suspend_handshake(true);
>> log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended, arming
>> ThreadSuspension", p2i(_handshakee));
>> ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake();
>> Handshake::execute(ts, _handshakee);
>>
>> Before we have enqueued the async handshake there is no trap and but the
>> flag set_suspend(true).
>> This means we will miss the async handshake and continue to executed with
>> suspended flag.
>>
>> Both flags and async handshake are set atomically by serializing over the
>> HnadshakeState lock.
>>
>> In this case we want to both know if we are suspended if so process the
>> suspension.
>
> (technically this will be ordered by the poll is since polls are only
> disarmed by threads them selfs)
> (meaning if you really promise to call should_process() after you have seen
> "set_suspend(true);" you will see the async handshake since then we do take
> the HandshakeState lock.)
> Also when the suspend request happened while A was blocked then after
> current->set_thread_state_fence(_thread_blocked_trans); the check of
> is_suspended() will return true even if the handshake state lock is not
> acquired for the check
That statement of mine is wrong. (Hopefully) correct is that after the complete
state change from _thread_blocked to _thread_in_vm which includes being blocked
for a safepoint/handshake the current thread would be able to check
is_suspended() without holding the handshake state lock. It does not make a lot
of sense then because in an unsafe state JavaThread::current()->is_suspended()
will always return false.
> Thread A wait on OM X in blocked.
> Thread Z suspends Thread A, thread Z have no relation to OM X.
> Thread B unlocks OM X, thread B have no relation to the suspend request.
> Thread A locks OM X while blocked.
> Thread A was not allowed to lock OM X due to it is actually suspended.
> Thread A unlocks OM X and waits until resumed.
I understand that example now too: OM and suspend operations are unrelated. So I
thought it would be ok for A to enter OM X, but it is not. A thread must not
leave a safe state if it was suspended in that state (with a handshake). If it
did, e.g., its stack could become not walkable. And it must not enter the
monitor either.
Sorry for the confusion. The check is good.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3191
