On Thu, 24 Oct 2024 03:01:40 GMT, David Holmes <[email protected]> wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
>
>> 950: for (;;) {
>> 951: boolean unblocked = false;
>> 952: synchronized (timedWaitLock()) {
>
> Where is the overall design of the timed-wait protocol and it use of
> synchronization described?
When we unmount on a timed-wait call we schedule a wakeup task at the end of
`afterYield`. There are two mechanisms that avoid the scheduled task to run and
wake up the virtual thread on a future timed-wait call, since in this call the
virtual thread could have been already notified before the scheduled task runs.
The first one is to cancel the scheduled task once we return from the wait call
(see `Object.wait(long timeoutMillis)`). Since the task could have been already
started though, we also use `timedWaitSeqNo`, which the wake up task checks
here to make sure it is not an old one. Since we synchronize on `timedWaitLock`
to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before
scheduling the wake up task in `afterYield`, here either a wrong
`timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing
to do. The only exception is checking for `SUSPENDED` state, in which case we
just loop to retry.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381
