Date: Tue, 11 Apr 2017 19:55:57 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Eric van Gyzen <eric@vangyzen.net> Cc: redraiment@gmail.com, freebsd-java@freebsd.org, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: OpenJDK8 Thread.sleep will deadlock while turn down system date time. Message-ID: <Pine.GSO.4.64.1704111923550.21979@sea.ntplx.net> In-Reply-To: <a48038a5-3f12-f7ef-9e94-6c33b4672c02@vangyzen.net> References: <CAPRzLQSOfySJWqN8CoLNchRs_JgHkeQz57ZNB9E__Meip3zmOQ@mail.gmail.com> <20170408070340.GD1788@kib.kiev.ua> <a48038a5-3f12-f7ef-9e94-6c33b4672c02@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Apr 2017, Eric van Gyzen wrote: > On 4/8/17 2:03 AM, Konstantin Belousov wrote: [ ... ] >> >> If JVM sets timeouts using absolute times than it might be fixed in latest >> HEAD and stable/11. > > The JVM uses pthread_cond_timedwait() to implement Thread.sleep(), so it > always uses absolute times. Furthermore, it uses the default clock, > CLOCK_REALTIME. My recent change (r315280) does not fix this behavior; in > fact, I believe it will make the problem worse, since moving the clock > forward will wake the thread prematurely. > > I think the JVM should be fixed to use CLOCK_MONOTONIC. Would someone like > to do the research to determine the correct behavior of Thread.sleep()? > Specifically, should the duration of the sleep be affected by adjustments to > the real-time clock? I expect that it should /not/ be affected, especially > since the API takes a relative/interval time. Ideally, we would find the > answer in the formal language specification; failing that, I would be > satisfied with empirical data from testing on Windows, Linux, MacOS, and > Solaris. I'll be happy to write a patch once we know what it should do. > > Please keep me CC'd, since I'm not on freebsd-java@. (Thanks for the CC, > Kostik.) It seems CLOCK_REALTIME behavior has bugged Linux in the past, too. I think using CLOCK_MONOTONIC, perhaps via pthread_condattr_setclock() in our JVM, would be the better approach. You'd probably also want to check that whatever java.util.concurrent relies on, if different, also behaves similarly (monotonically). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1704111923550.21979>