Re: More accurate wording for java.util.concurrent.TimeUnit.sleep

Let's leave out the correctness, the corner cases and just discuss the idea
behind that code. I think David put this nicely in his previous email:

...To ensure sleeping "at least" the amount specified may mean sleeping
considerably longer - which for short sleeps can be worse than returning
slightly early...

I personally think of Thread.sleep as of the most low-level function that
provides the functionality of sleeping. It's up to each individual consumer
of this functionality to extend and to build on top of it.

Consider this totally fictional example from everyday life. You have a
super important thing to attend to at 9 am sharp. You wake up at night and
glance at your watch. You still have 3 hours of sleep. The next time you
wake up, you realize you have only 20 mins left. Now here's a question.
Would you better get off the bed straight away or would you take your
chances and sleep for another 20 mins? As the next time you look at your
watch, it may display noon.


On Fri, Aug 30, 2019 at 2:58 PM Thorsten Goetzke via Concurrency-interest <
[email protected]> wrote:

> Just for my personal interest:
> Is there something wrong with the code
> below? Couldn't just the Thread.sleep java side implemtation get updated
> accordingly?
>
> void sleep (long timeout){
> final long l = System.currentTimeMillis();
> long remaining = timeout;
>    do {
>          Thread.sleep(remaining);
>          remaining = l - System.currentTimeMillis() + timeout;
> } while (remaining > 0);
> }
>
> You may (or should) also use System.nanoTime instead of currentTimeMillis.
>
> Over the years i have seen a lot of
> Thread.sleep(100)
> Thread.sleep(1)//we need to sleep a bit longer because sleep wakes up to
> early!!!
>
> And as much as i hate the code and the comment, there is a reason people
> type this.
>
>
>
> Am 30.08.19 um 15:25 schrieb David Holmes:
> > Thread.sleep on Windows can return early. That's a long standing bug
> that I'm currently looking at addressing. Thread.sleep is not subject to
> "spurious wakeups" - that's only for Object.wait() and LockSupport.park().
> The higher-level synchronizers don't allow spurious wakeups or early
> returns.
> >
> > Note that the Windows timed-wait API are all specified to be able to
> return up to a "tick" early - and a tick can be as bad as 16ms!
> >
> > BTW the claim that a sleep time of zero does not sleep at all is also
> not quite accurate - it's implemented as a "yield" so may or may not
> actually result in the thread going off CPU. As Doug used to put it
> sleep(0) means "sleep for at least no time". 😊
> >
> > I know it always seems that these things should be easy to specify and
> implement precisely, but it's never quite that simple. To ensure sleeping
> "at least" the amount specified may mean sleeping considerably longer -
> which for short sleeps can be worse than returning slightly early. Things
> are not as bad as they were 20 years ago though.
> >
> > Cheers,
> > David
> >
> >> -----Original Message-----
> >> From: Concurrency-interest On Behalf Of Thorsten Goetzke via
> Concurrency-interest
> >> Sent: Friday, August 30, 2019 10:02 PM
> >> To: [email protected]
> >> Subject: [concurrency-interest] More accurate wording for
> java.util.concurrent.TimeUnit.sleep
> >>
> >> Hello,
> >>
> >> I asked a similar question pretty much exactly a year ago.
> >> My interpretation of the answer would be that the jvm should no longer
> wake up to early (spurios wakeups for multithreaded
> >> scenarios may still happen).
> >> Earlier versions of the jvm do tend to wake up to early.
> >> @Martin Buchholz ist that correct?
> >>
> >>
> >>
> http://cs.oswego.edu/pipermail/concurrency-interest/2018-August/016501.html
> >>
> http://cs.oswego.edu/pipermail/concurrency-interest/2018-August/016510.html
> >>
> >>
> >> Am 30.08.19 um 13:21 schrieb Pavel Rappo via Concurrency-interest:
> >>> While reading the javadoc for the java.util.concurrent.TimeUnit.sleep
> >>> method I noticed an inconsistency.
> >>>
> >>> "...@param timeout the minimum time to sleep. If less than or equal to
> >>> zero, do not sleep at all..."
> >>>
> >>> I'd argue that the use of the word "minimum" there might be
> >>> misleading. Thread.sleep (which TimeUnit.sleep claims to delegate the
> >>> sleeping to) does not give that guarantee. It simply states
> >>>
> >>> "...@param millis the length of time to sleep in milliseconds..."
> >>>
> >>> Moreover, the spec for Thread.sleep has a special clause that suggests
> >>> that the thread may sleep inaccurately, possibly even less than the
> >>> specified amount of time:
> >>>
> >>> "...subject to the precision and accuracy of system timers and
> schedulers..."
> >>>
> >>> Thanks,
> >>> -Pavel
> >>> _______________________________________________
> >>> Concurrency-interest mailing list
> >>> [email protected]
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> [email protected]
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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