RFR 8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock (original) (raw)

Martin Buchholz martinrb at google.com
Wed Aug 29 21:36:14 UTC 2018

Thanks for taking this on. Wait loops are notoriously hard to get right...

One sharp corner is that wait(0) waits forever, and TimeUnit conversion truncates. You can probably avoid those problems via TimeUnit.timedWait.

In code like this in j.u.c. we try to optimize away the call to nanoTime when waiting is not necessary, by using a special "uninitialized" initial value for remaining nanos, e.g. in FutureTask.awaitDone

    long startTime = 0L;    // Special value 0L means not yet parked

(I prefer the variable name "startTime")

(j.u.c. code can also be improved)

(there's a pre-existing buglet - we should probably check for overflow when millis = MAX_VALUE and nanos > 0 (sigh))

(I would reorder clauses to first check the common case millis > 0, then millis == 0, last the error case millis < 0)

(it's a bad API that millis < 0 is an error)

On Wed, Aug 29, 2018 at 1:06 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

Please review changes for:

8098798: Thread.join(ms) on Linux still affected by changes to the time-of-day clock Use System.nanoTime to compute any remaining delay 8210004: Thread.sleep(millis, nanos) timeout returns early Avoid an early return by rounding the milliseconds up if there are any nanoseconds as was done in Object.wait(ms, ns). (If its not appropriate to do the two reviews together, I can split them). Webrev: http://cr.openjdk.java.net/~rriggs/webrev-thread-early-8098798/ Thanks, Roger

More information about the core-libs-dev mailing list