Sleep time consistency compared to System.currentTimeMillis

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
Hello,

There are multiple Classes that let you wait or sleep for a specified
amount of time. My current understanding is:
Thread.sleep and Object.wait can wake up earlier than specified so code
that also uses System.currentTimeMillies can break because wakeups
happen to early.
On the other side code that uses higher level Abstraction such as
ScheduledExecutorService or CountDownLatch.await will always at least
wait for the specified time and it will be consistent with
System.currentTimeMillies. Is that actually correct and guaranteed or is
is just implementation dependent?

Best regards,
Thorsten Goetzke
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
Hi Thorsten,

Why do you think that Thread.sleep can wake up earlier than was requested? There is no mention of this in the spec. Thread.sleep will never wake up earlier, but besides that, you have no guarantees except "the best effort to not exceed the specified time interval by much".

>code that also uses System.currentTimeMillies can break because wakeups happen to early
Thread.sleed definitely can't use System.currentTimeMillies, because currentTimeMillies is not monotonic (it's just a system time, which can easily go backwards). If you are trying to reliably measure an interval of time, use System.nanoTime because it is monotonic (this method is specifically there to provide a tool for measuring time intervals).

Regards,
Valentin
LinkedIn   GitHub   YouTube


On Fri, 24 Aug 2018 at 10:02, <[hidden email]> wrote:
Send Concurrency-interest mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

   1. Sleep time consistency compared to        System.currentTimeMillis
      (Thorsten Goetzke)


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

Message: 1
Date: Fri, 24 Aug 2018 11:10:20 +0200
From: Thorsten Goetzke <[hidden email]>
To: [hidden email]
Subject: [concurrency-interest] Sleep time consistency compared to
        System.currentTimeMillis
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hello,

There are multiple Classes that let you wait or sleep for a specified
amount of time. My current understanding is:
Thread.sleep and Object.wait can wake up earlier than specified so code
that also uses System.currentTimeMillies can break because wakeups
happen to early.
On the other side code that uses higher level Abstraction such as
ScheduledExecutorService or CountDownLatch.await will always at least
wait for the specified time and it will be consistent with
System.currentTimeMillies. Is that actually correct and guaranteed or is
is just implementation dependent?

Best regards,
Thorsten Goetzke


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

Subject: Digest Footer

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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

End of Concurrency-interest Digest, Vol 162, Issue 12
*****************************************************

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list

I do not have an answer for you.  However, I do not think Java is completely in control.  I recommend you look at the source code for Thread.sleep() including the JVM code.  This will show you what system APIs are called.  You can then look at the documentation for the system APIs.

Here is some anecdotal information.  We recently started using Netdata to track resource usage.  One metric that Netdata tracks is idle jitter.  Here's the Netdata description.


Idle jitter is calculated by netdata. A thread is spawned that requests to sleep for a few microseconds. When the system wakes it up, it measures how many microseconds have passed. The difference between the requested and the actual duration of the sleep, is the idle jitter. This number is useful in real-time environments, where CPU jitter can affect the quality of the service (like VoIP media gateways).

I have not tuned the machine to minimize idle jitter.  I am seeing an idle jitter of up to 10 ms!  This suggests to me that Thread.sleep(1) could return up to 10 ms later.  For my application, I do not think this is a big deal.  I am not doing any time sensitive operations.  I pasted in the idle jitter graph.  I hope it makes it through the mail.

-Nathan
On 8/24/2018 11:38 AM, Valentin Kovalenko via Concurrency-interest wrote:
Hi Thorsten,

Why do you think that Thread.sleep can wake up earlier than was requested? There is no mention of this in the spec. Thread.sleep will never wake up earlier, but besides that, you have no guarantees except "the best effort to not exceed the specified time interval by much".

>code that also uses System.currentTimeMillies can break because wakeups happen to early
Thread.sleed definitely can't use System.currentTimeMillies, because currentTimeMillies is not monotonic (it's just a system time, which can easily go backwards). If you are trying to reliably measure an interval of time, use System.nanoTime because it is monotonic (this method is specifically there to provide a tool for measuring time intervals).

Regards,
Valentin
LinkedIn   GitHub   YouTube


On Fri, 24 Aug 2018 at 10:02, <[hidden email]> wrote:
Send Concurrency-interest mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

   1. Sleep time consistency compared to        System.currentTimeMillis
      (Thorsten Goetzke)


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

Message: 1
Date: Fri, 24 Aug 2018 11:10:20 +0200
From: Thorsten Goetzke <[hidden email]>
To: [hidden email]
Subject: [concurrency-interest] Sleep time consistency compared to
        System.currentTimeMillis
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

Hello,

There are multiple Classes that let you wait or sleep for a specified
amount of time. My current understanding is:
Thread.sleep and Object.wait can wake up earlier than specified so code
that also uses System.currentTimeMillies can break because wakeups
happen to early.
On the other side code that uses higher level Abstraction such as
ScheduledExecutorService or CountDownLatch.await will always at least
wait for the specified time and it will be consistent with
System.currentTimeMillies. Is that actually correct and guaranteed or is
is just implementation dependent?

Best regards,
Thorsten Goetzke


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

Subject: Digest Footer

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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

End of Concurrency-interest Digest, Vol 162, Issue 12
*****************************************************

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
On 08/24/2018 05:10 AM, Thorsten Goetzke via Concurrency-interest wrote:
> Hello,
>
> There are multiple Classes that let you wait or sleep for a specified
> amount of time. My current understanding is:
> Thread.sleep and Object.wait can wake up earlier than specified so code
> that also uses System.currentTimeMillies can break because wakeups
> happen to early.

Yes, and the JDK API specs for these methods include disclaimers,
including: "The specified amount of real time has elapsed, more or less."

> On the other side code that uses higher level Abstraction such as
> ScheduledExecutorService or CountDownLatch.await will always at least
> wait for the specified time and it will be consistent with
> System.currentTimeMillies. Is that actually correct and guaranteed


Yes, java.util.concurrent time-based API specs do not include any such
disclaimers, so you will never get a too-short wait. Delays may be
arbitrarily longer than you'd like though. Imagine millions of threads
waiting for a millisecond. Not all of them will start running after a
millisecond.

-Doug
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
As Carl Mastrangelo <[hidden email]> pointed out (he accidentally replied not to the whole group, but just me):

Apparently, there is a corresponding bug report: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8098798
But since the priority is P4, I am assuming it will hardly be fixed in the observable future.

There is also a bug report about the wording "Waits at most millis milliseconds for this thread to die" in the Thread.join docs: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4132653
Unfortunately, this one was rejected with the phrase "Changing the specification is no longer possible to the extent proposed" (I am not sure what this is supposed to mean).

Regards,
Valentin
LinkedIn   GitHub   YouTube


On Sat, 25 Aug 2018 at 10:01, <[hidden email]> wrote:
Send Concurrency-interest mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

   1. Re: Sleep time consistency compared to
      System.currentTimeMillis (Doug Lea)


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

Message: 1
Date: Sat, 25 Aug 2018 09:57:46 -0400
From: Doug Lea <[hidden email]>
To: [hidden email]
Subject: Re: [concurrency-interest] Sleep time consistency compared to
        System.currentTimeMillis
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

On 08/24/2018 05:10 AM, Thorsten Goetzke via Concurrency-interest wrote:
> Hello,
>
> There are multiple Classes that let you wait or sleep for a specified
> amount of time. My current understanding is:
> Thread.sleep and Object.wait can wake up earlier than specified so code
> that also uses System.currentTimeMillies can break because wakeups
> happen to early.

Yes, and the JDK API specs for these methods include disclaimers,
including: "The specified amount of real time has elapsed, more or less."

> On the other side code that uses higher level Abstraction such as
> ScheduledExecutorService or CountDownLatch.await will always at least
> wait for the specified time and it will be consistent with
> System.currentTimeMillies. Is that actually correct and guaranteed


Yes, java.util.concurrent time-based API specs do not include any such
disclaimers, so you will never get a too-short wait. Delays may be
arbitrarily longer than you'd like though. Imagine millions of threads
waiting for a millisecond. Not all of them will start running after a
millisecond.

-Doug


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

Subject: Digest Footer

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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

End of Concurrency-interest Digest, Vol 162, Issue 14
*****************************************************

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list

Hi Valentin,

 

It seems 8098798 slipped past the notice of those of us who have a keen interest in such matters. It should be fixed and I’ve already updated the bug.

 

4132653 is a non-issue. It was closed simply because it was 20 years old (I agree the chosen text is a little strange 😊 ). The suggestion in the bug report is not right (no blocking time should ever be interpreted as meaning a time when the thread actually gets a CPU again – it only affects eligibility to get a CPU) and we don’t always wait “at least” the timeout because the thread may die sooner. The intent is quite clear that join(ms) while wait for up to ms milliseconds for the thread to die.

 

Cheers,

David

 

From: Concurrency-interest <[hidden email]> On Behalf Of Valentin Kovalenko via Concurrency-interest
Sent: Monday, August 27, 2018 4:26 AM
To: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] Sleep time consistency compared to System.currentTimeMillis

 

As Carl Mastrangelo <[hidden email]> pointed out (he accidentally replied not to the whole group, but just me):

 

Apparently, there is a corresponding bug report: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8098798

But since the priority is P4, I am assuming it will hardly be fixed in the observable future.

 

There is also a bug report about the wording "Waits at most millis milliseconds for this thread to die" in the Thread.join docs: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4132653

Unfortunately, this one was rejected with the phrase "Changing the specification is no longer possible to the extent proposed" (I am not sure what this is supposed to mean).


Regards,

Valentin

Image removed by sender. LinkedIn   Image removed by sender. GitHub   Image removed by sender. YouTube

 

On Sat, 25 Aug 2018 at 10:01, <[hidden email]> wrote:

Send Concurrency-interest mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://cs.oswego.edu/mailman/listinfo/concurrency-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Concurrency-interest digest..."


Today's Topics:

   1. Re: Sleep time consistency compared to
      System.currentTimeMillis (Doug Lea)


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

Message: 1
Date: Sat, 25 Aug 2018 09:57:46 -0400
From: Doug Lea <[hidden email]>
To: [hidden email]
Subject: Re: [concurrency-interest] Sleep time consistency compared to
        System.currentTimeMillis
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8

On 08/24/2018 05:10 AM, Thorsten Goetzke via Concurrency-interest wrote:
> Hello,
>
> There are multiple Classes that let you wait or sleep for a specified
> amount of time. My current understanding is:
> Thread.sleep and Object.wait can wake up earlier than specified so code
> that also uses System.currentTimeMillies can break because wakeups
> happen to early.

Yes, and the JDK API specs for these methods include disclaimers,
including: "The specified amount of real time has elapsed, more or less."

> On the other side code that uses higher level Abstraction such as
> ScheduledExecutorService or CountDownLatch.await will always at least
> wait for the specified time and it will be consistent with
> System.currentTimeMillies. Is that actually correct and guaranteed


Yes, java.util.concurrent time-based API specs do not include any such
disclaimers, so you will never get a too-short wait. Delays may be
arbitrarily longer than you'd like though. Imagine millions of threads
waiting for a millisecond. Not all of them will start running after a
millisecond.

-Doug


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

Subject: Digest Footer

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


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

End of Concurrency-interest Digest, Vol 162, Issue 14
*****************************************************


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
> On 08/24/2018 05:10 AM, Thorsten Goetzke via Concurrency-interest wrote:
>> Hello,
>>
>> There are multiple Classes that let you wait or sleep for a specified
>> amount of time. My current understanding is:
>> Thread.sleep and Object.wait can wake up earlier than specified so code
>> that also uses System.currentTimeMillies can break because wakeups
>> happen to early.
>
> Yes, and the JDK API specs for these methods include disclaimers,
> including: "The specified amount of real time has elapsed, more or less."
>

I think in case of Thread.sleep the javadoc should be clarified so it
explicitly contains the word "less".
It just says "subject to the precision and accuracy of system timers and
schedulers" which can be missunderstood as "at least sleep time + the
jvm does it's best to reduce additional sleep time but it obviosly cant
magically make the undlerying system more precise".

https://docs.oracle.com/javase/10/docs/api/java/lang/Thread.html#sleep(long)


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
IMHO if your code breaks because Thread.sleep woke up too early or too late, your code was incorrect to start with.  Same with wait(), which can be subject to spurious wakeups apparently.  But even if that happens, correct code would still work :-)

My thumb rule with wait() is to always write it in such a way that it would also work with notifyAll(), whether you use that or notify().  If you do, it will still work with spurious wake ups or lost races for the lock.

For time sensitive waiting, I prefer Condition.awaitMillis(). 

It is of course neither precise nor real-time. 

Heinz

On Mon, 27 Aug 2018 at 11:38, Thorsten Goetzke via Concurrency-interest <[hidden email]> wrote:
> On 08/24/2018 05:10 AM, Thorsten Goetzke via Concurrency-interest wrote:
>> Hello,
>>
>> There are multiple Classes that let you wait or sleep for a specified
>> amount of time. My current understanding is:
>> Thread.sleep and Object.wait can wake up earlier than specified so code
>> that also uses System.currentTimeMillies can break because wakeups
>> happen to early.
>
> Yes, and the JDK API specs for these methods include disclaimers,
> including: "The specified amount of real time has elapsed, more or less."
>

I think in case of Thread.sleep the javadoc should be clarified so it
explicitly contains the word "less".
It just says "subject to the precision and accuracy of system timers and
schedulers" which can be missunderstood as "at least sleep time + the
jvm does it's best to reduce additional sleep time but it obviosly cant
magically make the undlerying system more precise".

https://docs.oracle.com/javase/10/docs/api/java/lang/Thread.html#sleep(long)


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun/Oracle Java Champion
JavaOne Rockstar Speaker
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
> IMHO if your code breaks because Thread.sleep woke up too early or too
> late, your code was incorrect to start with.  Same with wait(), which
> can be subject to spurious wakeups apparently.

Well it's not productive code, the situation is: We want to  simulate
code, (for testing purpose) that does't return for 123 (or whatever)
millisecends or more (for example to simulate a query-timeout). It just
a bit sad that the most simple, straightforward approach sleep(123)
breaks on some machines because it doesn't actually sleeps as long as
needed. It's easily fixable when you know what's going on, but you have
to be aware.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
Thread.jjoin(long) should be fixed to use nanoTime instead of currentTimeMillis.

Thread.wait's spec should be fixed to remove the "more or less" (although spurious wakeup remains possible).

Thread.sleep should be fixed to not wake up early due to rounding of nanos (as Object.wait was fixed).

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
That's good to hear it was a bug.  I had asked about in on Stack Overflow* a while ago, and no one seemed to recognize it should be fixed.



On Mon, Aug 27, 2018 at 7:06 AM Martin Buchholz via Concurrency-interest <[hidden email]> wrote:
Thread.jjoin(long) should be fixed to use nanoTime instead of currentTimeMillis.

Thread.wait's spec should be fixed to remove the "more or less" (although spurious wakeup remains possible).

Thread.sleep should be fixed to not wake up early due to rounding of nanos (as Object.wait was fixed).
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Sleep time consistency compared to System.currentTimeMillis

JSR166 Concurrency mailing list
https://bugs.openjdk.java.net/browse/JDK-8210004
http://hg.openjdk.java.net/jdk/jdk/rev/13d6be5fbfa5

On Mon, Aug 27, 2018 at 10:23 AM, Carl Mastrangelo <[hidden email]> wrote:

> That's good to hear it was a bug.  I had asked about in on Stack Overflow* a
> while ago, and no one seemed to recognize it should be fixed.
>
>
> *
> https://stackoverflow.com/questions/42544387/why-does-thread-join-use-currenttimemillis
>
> On Mon, Aug 27, 2018 at 7:06 AM Martin Buchholz via Concurrency-interest
> <[hidden email]> wrote:
>>
>> Thread.jjoin(long) should be fixed to use nanoTime instead of
>> currentTimeMillis.
>>
>> Thread.wait's spec should be fixed to remove the "more or less" (although
>> spurious wakeup remains possible).
>>
>> Thread.sleep should be fixed to not wake up early due to rounding of nanos
>> (as Object.wait was fixed).
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest