-
Bug
-
Resolution: Fixed
-
P3
-
e5.0u21, hs24, hs25, 6, 6u29, 7
-
b109
-
generic, x86, ppc
-
linux, linux_ubuntu
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8034496 | 7u65 | David Holmes | P3 | Closed | Fixed | b01 |
JDK-8024878 | 7u60 | David Holmes | P3 | Closed | Fixed | b01 |
JDK-8025563 | 6u71 | Sergey Gabdurakhmanov | P3 | Closed | Fixed | b01 |
JDK-8024859 | hs25 | David Holmes | P3 | Closed | Fixed | b51 |
The real fix here is to change the pthread_cond so that it is associated with the monotonic clock (pthread_condattr_setclock(CLOCK_MONOTONIC) - and with pthread_cond_init being passed the attr object) and to calculate the asbolute time as "millis from now" on the monotonic clock. This will make the PlatformEvent::park(millis) code immune to changes in the time-of-day clock.
This change is relatively simple but it does affect all timed-waiting calls that ultimately use PlatformEvent. This should be okay as the majority of Java APIs that involve timed-waiting all specify relative times the same as Thread.sleep. I believe this will cover Thread.sleep and Object.wait.
Note that there is a similar problem with the java.util.concurrent.locks.LockSupport.park methods which are implemented using the platform specific Parker class, which again uses a pthread_mutex and pthread_cond under the covers. However as they support both absolute and relative wait times the fix is more involved as we need to use the monotonic clock for relative waits, but the TOD clock for absolute ones! That would require using two different pthread_cond objects.
Update: Note that time jump forwards lead to early returns. For os::sleep there is a guard in place to prevent this already. For wait(ms) and park(nanos) such a guard could also be implemented but is unnecessary in practice because an early timeout can not be distinguished from a "spurious wakeup" which is permitted by the spec and which Java code has to account for.
- backported by
-
JDK-8024859 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
- Closed
-
JDK-8024878 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
- Closed
-
JDK-8025563 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
- Closed
-
JDK-8034496 PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock
- Closed
- duplicates
-
JDK-8024036 Thread.sleep(long) is not immune to system time shifts with Linux kernel 3.7.10
- Closed
-
JDK-7139684 ScheduledExecutorService doesn't schedules correctly if sys time drifts back
- Closed
- relates to
-
JDK-6311057 Java Thread.sleep(timeout) is influenced by changes to System time on Linux
- Closed
-
JDK-8226219 [Linux] Park(millis) can use the wrong clock if pthread_condattr_setclock failed
- Closed
-
JDK-8029453 java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java failed by timeout
- Closed
-
JDK-6546236 Thread interrupt() of Thread.sleep() can be lost on Solaris due to race with signal handler
- Closed
-
JDK-8024036 Thread.sleep(long) is not immune to system time shifts with Linux kernel 3.7.10
- Closed
-
JDK-8144167 [OS_X] ConditionObject#awaitNanos waits too long if system clock is turned back
- Closed