[crac] RFR: Wake up all TIMED_WAITING threads after restore

Anton Kozlov akozlov at openjdk.org
Mon Jun 19 15:55:33 UTC 2023


On Mon, 19 Jun 2023 14:46:35 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> 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()?

src/hotspot/os/linux/os_linux.cpp line 6124:

> 6122:   assert(list != NULL, "Thread list is null");
> 6123:   for (uint i = 0; i < list->length(); ++i) {
> 6124:     JavaThread* t = list->thread_at(i);

Please use Threads::threads_do, that includes non-Java threads as well.

src/hotspot/os/linux/os_linux.cpp line 6132:

> 6130:       t->interrupt();
> 6131:       t->osthread()->set_interrupted(false);
> 6132:     }

I think the problem of the native implementation of the timed wait is being fixed on the wrong level of abstraction. The interrupt() is much higher leve operation than the pthread_cond_signal, that we are actually targeting. And the latter would be also much cheaper. Could you replace the code with signaling every cond?

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

PR Comment: https://git.openjdk.org/crac/pull/85#issuecomment-1597418613
PR Review Comment: https://git.openjdk.org/crac/pull/85#discussion_r1234210999
PR Review Comment: https://git.openjdk.org/crac/pull/85#discussion_r1234235422


More information about the crac-dev mailing list