[crac] RFR: Wake up all TIMED_WAITING threads after restore
Radim Vansa
rvansa at openjdk.org
Fri Jun 30 08:08:18 UTC 2023
On Mon, 19 Jun 2023 15:52:59 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:
>> This is a fix for an issue found by @jankratochvil when testing #53: Threads that enter sleep or timed parking use absolute monotonic time for pthread_cond_timedwait(). When the monotonic time changes during C/R we need to wake all threads to readjust the timeout to the new absolute time.
>>
>> This introduces effectively a spurious wakeup; this is permitted for all the uses of pthread_cond_timedwait. Implementation either handles that transparently or propagates the wakeup to Java.
>>
>> This commit does not handle timed waiting in non-Java threads other than WatcherThread.
>
>> Threads that enter sleep or timed parking use absolute monotonic time for pthread_cond_wait().
>
> Probably pthread_cond_timedwait() ? Should not be other *_timedwait be handled, like sem_timedwait()?
>
>> When the monotonic time changes during C/R we need to wake all threads to readjust the timeout to the new absolute time.
>
> I assume this happens in the implementation of pthread_cond_timedwait and not the JVM caller function? Otherwise I can't see the code doing the recalculation.
>
>> This introduces effectively a spurious wakeup; this is permitted for all the uses of pthread_timed_wait.
>> Implementation either handles that transparently or propagates the wakeup to Java.
>
> OS-level spurious wake-ups are fine, but propogating that to java level seems dangerous. I could not spot the example of the propogation. E.g. can that happen to Thread.sleep()?
@AntonKozlov Updated, removing the OS thread state and using `as_Java_thread()`
-------------
PR Comment: https://git.openjdk.org/crac/pull/85#issuecomment-1614284093
More information about the crac-dev
mailing list