[concurrency-interest] Sleep time consistency compared to System.currentTimeMillis

David Holmes davidcholmes at aapt.net.au
Sun Aug 26 17:40:02 EDT 2018

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.





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


As Carl Mastrangelo <notcarl at google.com <mailto:notcarl at google.com> > pointed out (he accidentally replied not to the whole group, but just me):

Thread.join uses System.currentTimeMillis (see http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/lang/Thread.java#l1294).


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).



 <https://www.linkedin.com/in/stIncMale>     <https://github.com/stIncMale>     <https://www.youtube.com/user/stIncMale> 


On Sat, 25 Aug 2018 at 10:01, <concurrency-interest-request at cs.oswego.edu <mailto:concurrency-interest-request at cs.oswego.edu> > wrote:

Send Concurrency-interest mailing list submissions to
        concurrency-interest at cs.oswego.edu <mailto:concurrency-interest at cs.oswego.edu> 

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
        concurrency-interest-request at cs.oswego.edu <mailto:concurrency-interest-request at cs.oswego.edu> 

You can reach the person managing the list at
        concurrency-interest-owner at cs.oswego.edu <mailto:concurrency-interest-owner at cs.oswego.edu> 

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 <dl at cs.oswego.edu <mailto:dl at cs.oswego.edu> >
To: concurrency-interest at cs.oswego.edu <mailto:concurrency-interest at cs.oswego.edu> 
Subject: Re: [concurrency-interest] Sleep time consistency compared to
Message-ID: <0593feb8-924f-9e99-dc0e-a31ced2370a0 at cs.oswego.edu <mailto:0593feb8-924f-9e99-dc0e-a31ced2370a0 at cs.oswego.edu> >
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



Subject: Digest Footer

Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu> 


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180827/6d359cdd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20180827/6d359cdd/attachment-0001.jpg>

More information about the Concurrency-interest mailing list