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

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

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

JSR166 Concurrency mailing list
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
> [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: More accurate wording for java.util.concurrent.TimeUnit.sleep

JSR166 Concurrency mailing list
I've skimmed through that discussion thread, thanks. My impression is
that one of two things has to happen. Either the Thread.sleep spec
gets fixed or the TimeUnit.sleep spec gets fixed.

I don't buy the argument [*] that we can dismiss that concern since
all known implementations behave normally anyway, i.e. Thread.sleep
never returns earlier than the specified amount of time passes. It
smells like programming to an implementation rather than to an
interface.

--------------------
* Even if it were the case which we know it is not. See JDK-6313903.



On Fri, Aug 30, 2019 at 1:03 PM Thorsten Goetzke via
Concurrency-interest <[hidden email]> wrote:

>
> 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
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> 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: More accurate wording for java.util.concurrent.TimeUnit.sleep

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
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: [hidden email]
> 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
> > [hidden email]
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> _______________________________________________
> 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: More accurate wording for java.util.concurrent.TimeUnit.sleep

JSR166 Concurrency mailing list
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: [hidden email]
>> 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
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>> _______________________________________________
>> 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: More accurate wording for java.util.concurrent.TimeUnit.sleep

JSR166 Concurrency mailing list
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 <[hidden email]> 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: [hidden email]
>> 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
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>> _______________________________________________
>> 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

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
> On Fri, Aug 30, 2019 at 2:25 PM David Holmes via Concurrency-interest <[hidden email]> wrote:
>
> <snip>
>
> 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".

If I understand this correctly, TimeUnit.sleep does not try to specify
how Thread.sleep behaves. Instead, TimeUnit.sleep builds on top of
Thread.sleep's behavior by saying that if TimeUnit.sleep(timeout) is
called with timeout <= 0, then the Thread.sleep method is not called
at all. But I can definitely see how it might be confusing given that
TimeUnit.sleep is designed as "a convenience method that converts time
arguments into the form required by the {@code Thread.sleep} method."
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

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

JSR166 Concurrency mailing list
I've been a steady advocate of "at least" semantics for methods that specify a duration, including sleep.


Pavel, if you need to do something surely at 9am, set the alarm for 8am, not 9am!

I agree that if Thread.sleep(0) is not really a no-op then TimeUnit.sleep(0) should do the same thing.  Doug?

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list


On Fri, Aug 30, 2019 at 6:58 AM Thorsten Goetzke via Concurrency-interest <[hidden email]> wrote:

You may (or should) also use System.nanoTime instead of currentTimeMillis.

Yes, over the years we have replaced many calls to  currentTimeMillis with nanoTime, when interested in elapsed time.

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
> On Fri, Aug 30, 2019 at 6:00 PM Martin Buchholz <[hidden email]> wrote:
>
> I've been a steady advocate of "at least" semantics for methods that specify a duration, including sleep.
>
> https://bugs.openjdk.java.net/browse/JDK-6313903

Then it seems like you are in favor of changing the Thread.sleep spec.

> Pavel, if you need to do something surely at 9am, set the alarm for 8am, not 9am!

I never said in that example that the alarm is set for 9 am. I
shouldn't have used this analogy, to be honest. Analogies typically
lead to more confusion.

> I agree that if Thread.sleep(0) is not really a no-op then TimeUnit.sleep(0) should do the same thing.

Hm... We have to think carefully about that. My guess would be that
this "avoid Thread.sleep(0)" behavior has something to do with
consistency. You see, 0 (zero) can have a special meaning in some
APIs. For instance, java.util.concurrent treats it literally. Zero or
no time at all. On the other hand, java.net API typically treats it
"as an infinite timeout" (e.g. Socket.connect(SocketAddress, int)).
java.lang has it both ways. Thread.sleep is like java.util.concurrent
in that respect, but Thread.join and Object.wait(long) are like
java.net.

Having said that, I think TimeUnit tries to be consistent.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
Hi Pavel,

Yes my bad. Timeunit itself takes care of the <= 0 behaviour.

David

> -----Original Message-----
> From: Pavel Rappo
> Sent: Saturday, August 31, 2019 1:09 AM
> To: [hidden email]
> Cc: Thorsten Goetzke <[hidden email]>; David Holmes <[hidden email]>; concurrency-interest <concurrency-
> [hidden email]>
> Subject: Re: [concurrency-interest] More accurate wording for java.util.concurrent.TimeUnit.sleep
>
> > On Fri, Aug 30, 2019 at 2:25 PM David Holmes via Concurrency-interest <[hidden email]> wrote:
> >
> > <snip>
> >
> > 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".
>
> If I understand this correctly, TimeUnit.sleep does not try to specify how Thread.sleep behaves. Instead, TimeUnit.sleep builds on top
> of Thread.sleep's behavior by saying that if TimeUnit.sleep(timeout) is called with timeout <= 0, then the Thread.sleep method is not
> called at all. But I can definitely see how it might be confusing given that TimeUnit.sleep is designed as "a convenience method that
> converts time arguments into the form required by the {@code Thread.sleep} method."

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list

Martin,

 

I think we took the opportunity with TimeUnit to tighten up the loose specs from Thread.sleep. So I’m happy for TimeUnit to specify that <=0 is a no-op rather than some vague system level thing that may or may not actually have an observable affect.

 

Cheers,

David

 

From: Concurrency-interest On Behalf Of Martin Buchholz via Concurrency-interest
Sent: Saturday, August 31, 2019 3:00 AM
To: Pavel Rappo <[hidden email]>
Cc: concurrency-interest <[hidden email]>; David Holmes <[hidden email]>
Subject: Re: [concurrency-interest] More accurate wording for java.util.concurrent.TimeUnit.sleep

 

I've been a steady advocate of "at least" semantics for methods that specify a duration, including sleep.

 

 

Pavel, if you need to do something surely at 9am, set the alarm for 8am, not 9am!

 

I agree that if Thread.sleep(0) is not really a no-op then TimeUnit.sleep(0) should do the same thing.  Doug?


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

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

JSR166 Concurrency mailing list


On Fri, Aug 30, 2019 at 4:38 PM David Holmes <[hidden email]> wrote:

Martin,

 

I think we took the opportunity with TimeUnit to tighten up the loose specs from Thread.sleep. So I’m happy for TimeUnit to specify that <=0 is a no-op rather than some vague system level thing that may or may not actually have an observable affect.


 Oh, OK.  Another factoid I probably once knew and have now half-forgotten.

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list


On Fri, Aug 30, 2019 at 10:43 AM Pavel Rappo <[hidden email]> wrote:
> On Fri, Aug 30, 2019 at 6:00 PM Martin Buchholz <[hidden email]> wrote:
>
> I've been a steady advocate of "at least" semantics for methods that specify a duration, including sleep.
>
> https://bugs.openjdk.java.net/browse/JDK-6313903

Then it seems like you are in favor of changing the Thread.sleep spec.

Here's the 2005 version of Martin agreeing with you! 

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

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

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
On Fri, Aug 30, 2019 at 6:43 PM Pavel Rappo <[hidden email]> wrote:

> Hm... We have to think carefully about that. My guess would be that
> this "avoid Thread.sleep(0)" behavior has something to do with
> consistency. You see, 0 (zero) can have a special meaning in some
> APIs. For instance, java.util.concurrent treats it literally. Zero or
> no time at all. On the other hand, java.net API typically treats it
> "as an infinite timeout" (e.g. Socket.connect(SocketAddress, int)).
> java.lang has it both ways. Thread.sleep is like java.util.concurrent
> in that respect, but Thread.join and Object.wait(long) are like
> java.net.
>
> Having said that, I think TimeUnit tries to be consistent.

Revisiting this, I have probably made a poor word choice. I should've
used the word "uniform" instead of "consistent". Meaning that when one
uses TimeUnit, one always knows what a 0 (zero) timeout means.

Thread.sleep seems to be the only method from classic (pre Java 5)
concurrency that doesn't say anything about its behavior when zero is
passed. And it kinda makes sense when you think about it.

TimeUnit eliminates this need to think. And to be honest I like it.
Maybe that should be made more explicit by mentioning that design
choice in the class-level javadoc though. Something to the effect that
"unless otherwise stated... methods that accept timeout argument...
are no-op when that argument is less than or equal to zero...".
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest