[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