Thread.sleep in nanoseconds

[Andrew Connick]

I'm having some trouble using Thread.sleep(long millis, int nanos); it
seems to simply use the nanosecond argument to decide whether the
milliseconds argument should be rounded up or not.

When calling Thread.sleep(2, 0) in the body of a long-running for loop
the total time taken is approx. 7secs. This is the same time taken
using Thread.sleep(2, 499999). If I change the arguments and call
Thread.sleep(2,500000) the total time is over 10secs - exactly the
same as using Thread.sleep(3,0).

The API docs states "Causes the currently executing thread to sleep
(cease execution) for the specified number of milliseconds plus the
specified number of nanoseconds", but this is clearly not happening.

Could it be a problem with my JVM? I'm using Sun's Java 1.4.2_03.

Any help would be greatly appreciated!

--Andrew

 

[Michael Mangeng]

Hi Andrew,

Since the "normal" PC cannot even scedule precise milliseconds it is
useless to use the nanosecond argument.
(windows has a resolution to 10 ms, linux is a little bit more precise -
but i do not know the exact number here)

You are right.. if you look at the sources you see that this is exactly
what SUN did.. they round the milliseconds.

As far as i know - this method is only useful for real-time operating
systems only.

greets,
mike

 

[Steve W. Jackson]

:Hi Andrew,
:
:Since the "normal" PC cannot even scedule precise milliseconds it is
:useless to use the nanosecond argument.
windows has a resolution to 10 ms, linux is a little bit more precise -
:but i do not know the exact number here)
:
:You are right.. if you look at the sources you see that this is exactly
:what SUN did.. they round the milliseconds.
:
:As far as i know - this method is only useful for real-time operating
:systems only.
:
:greets,
:mike
:
:
:Andrew Connick wrote:
:> I'm having some trouble using Thread.sleep(long millis, int nanos); it
:> seems to simply use the nanosecond argument to decide whether the
:> milliseconds argument should be rounded up or not.
:>
:> When calling Thread.sleep(2, 0) in the body of a long-running for loop
:> the total time taken is approx. 7secs. This is the same time taken
:> using Thread.sleep(2, 499999). If I change the arguments and call
:> Thread.sleep(2,500000) the total time is over 10secs - exactly the
:> same as using Thread.sleep(3,0).
:>
:> The API docs states "Causes the currently executing thread to sleep
:> (cease execution) for the specified number of milliseconds plus the
:> specified number of nanoseconds", but this is clearly not happening.
:>
:> Could it be a problem with my JVM? I'm using Sun's Java 1.4.2_03.
:>
:> Any help would be greatly appreciated!
:>
:> --Andrew
:

Windows 98 only goes to 50 milliseconds, for what that's worth. In my
earlier testing with Mac OS X and Linux (Mandrake, in this case), both
went to 1 millisecond.

= Steve =

 

[Mark Thornton]

Windows 98 only goes to 50 milliseconds, for what that's worth. In my
earlier testing with Mac OS X and Linux (Mandrake, in this case), both
went to 1 millisecond.

= Steve =

You can in fact get sleep times down to around ~2ms on Windows XP or
2000 when using Thread.sleep. However measuring this is tricky as the
System.currentTimeMillis still has the usual 10ms or 15.625ms
resolution. This is done using special code when the requested sleep
time is less than 10ms.

Mark Thornton

 

[Steve W. Jackson]

:Steve W. Jackson wrote:
:> In article <[email protected]>,
:>
:>
:>>:Hi Andrew,
:>>:
:>>:Since the "normal" PC cannot even scedule precise milliseconds it is
:>>:useless to use the nanosecond argument.
:>windows has a resolution to 10 ms, linux is a little bit more precise -
:>>:but i do not know the exact number here)
:>>:
:>>:You are right.. if you look at the sources you see that this is exactly
:>>:what SUN did.. they round the milliseconds.
:>>:
:>>:As far as i know - this method is only useful for real-time operating
:>>:systems only.
:>>:
:>>:greets,
:>>:mike
:>>:
:>>:
:>>:Andrew Connick wrote:
:>>:> I'm having some trouble using Thread.sleep(long millis, int nanos); it
:>>:> seems to simply use the nanosecond argument to decide whether the
:>>:> milliseconds argument should be rounded up or not.
:>>:>
:>>:> When calling Thread.sleep(2, 0) in the body of a long-running for loop
:>>:> the total time taken is approx. 7secs. This is the same time taken
:>>:> using Thread.sleep(2, 499999). If I change the arguments and call
:>>:> Thread.sleep(2,500000) the total time is over 10secs - exactly the
:>>:> same as using Thread.sleep(3,0).
:>>:>
:>>:> The API docs states "Causes the currently executing thread to sleep
:>>:> (cease execution) for the specified number of milliseconds plus the
:>>:> specified number of nanoseconds", but this is clearly not happening.
:>>:>
:>>:> Could it be a problem with my JVM? I'm using Sun's Java 1.4.2_03.
:>>:>
:>>:> Any help would be greatly appreciated!
:>>:>
:>>:> --Andrew
:>>:
:>
:>
:> Windows 98 only goes to 50 milliseconds, for what that's worth. In my
:> earlier testing with Mac OS X and Linux (Mandrake, in this case), both
:> went to 1 millisecond.
:>
:> = Steve =
:
:You can in fact get sleep times down to around ~2ms on Windows XP or
:2000 when using Thread.sleep. However measuring this is tricky as the
:System.currentTimeMillis still has the usual 10ms or 15.625ms
:resolution. This is done using special code when the requested sleep
:time is less than 10ms.
:
:Mark Thornton
:

Sorry, I suppose I should've been more clear in what I posted. I
haven't made any effort to measure sleep times. What I did once upon a
time was a rudimentary attempt at timing some code for performance
reasons (trying to identify the source of a bottleneck). In doing that,
I learned that System.currentTimeMillis() in Windows 98 only went down
to 50 ms intervals, whereas 2000 and XP both reported lower (I think it
probably was 10, can't remember), and in Linux and Mac OS X it was 1 ms.

= Steve =

 

[Tony Morris]

Here is a typical SCJP exam question:

What does the java.lang.Thread#sleep(long) method do ?

a) Puts the current thread into a wait state for the specified milliseconds.
b) Puts the thread instance that the method is invoked on, into a wait state
for the specified milliseconds.
c) Puts the current thread into a wait state for at least the specified
milliseconds.

The correct answer is c), which makes you wonder about the value of passing
the number of nanoseconds.
The thread scheduler will "sleep" the thread for the specified amount of
time, but then it will place the thread back into a "ready" state (not a
"running" state). It is then up to the thread scheduler to determine when
to bring the thread into running state, from ready state.


--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Tim Ward]

Since the "normal" PC cannot even scedule precise milliseconds

Well, Windows does have much more precise timers, actually, but the Java VMs
I've used choose not to use those APIs and use a much cruder timer instead,
so this is a Java issue. However if real time behaviour is wanted a real
time operating system is needed.

 

[xarax]

Here is a typical SCJP exam question:

What does the java.lang.Thread#sleep(long) method do ?

a) Puts the current thread into a wait state for the specified milliseconds.
b) Puts the thread instance that the method is invoked on, into a wait state
for the specified milliseconds.
c) Puts the current thread into a wait state for at least the specified
milliseconds.

The correct answer is c), which makes you wonder about the value of passing
the number of nanoseconds.
The thread scheduler will "sleep" the thread for the specified amount of
time, but then it will place the thread back into a "ready" state (not a
"running" state). It is then up to the thread scheduler to determine when
to bring the thread into running state, from ready state.

/snip/

A reasonable interpretation of the sleep() documentation
is that the thread will wait without consuming CPU
time for *at least* the time interval specified, unless
interrupted. The amount of time that actually elapses
(without an interrupt) before the thread resumes is
variable, but should never be less than the specified
time interval. The JVM will make a "best effort" to
resume the thread with reasonably little delay after
the time interval has expired. Similar remarks apply
to the wait() method that accepts a time interval.


--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!

 

[Mark Thornton]

Sorry, I suppose I should've been more clear in what I posted. I
haven't made any effort to measure sleep times. What I did once upon a
time was a rudimentary attempt at timing some code for performance
reasons (trying to identify the source of a bottleneck). In doing that,
I learned that System.currentTimeMillis() in Windows 98 only went down
to 50 ms intervals, whereas 2000 and XP both reported lower (I think it
probably was 10, can't remember), and in Linux and Mac OS X it was 1 ms.

= Steve =

You might be interested in the class sun.misc.Perf found in 1.4.2. It
provides high resolution timing information (the frequency is >3MHz on
this system).

Perf p = Perf.getPerf();
long t = p.highResCounter();
long freq = p.highResFreq();

(From memory)
I think something similar is likely to appear officially in 1.5.

Mark Thornton

 

[Steve W. Jackson]

[ snip ]

:
:You might be interested in the class sun.misc.Perf found in 1.4.2. It
rovides high resolution timing information (the frequency is >3MHz on
:this system).
:
erf p = Perf.getPerf();
:long t = p.highResCounter();
:long freq = p.highResFreq();
:
From memory)
:I think something similar is likely to appear officially in 1.5.
:
:Mark Thornton
:

That might be useful. Trouble is, I don't know how to get *any*
information on those undocumented classes sun.*. Got a pointer?

= Steve =

 

[Andrew Thompson]

"Steve W. Jackson" ...
| Mark Thornton wrote:
....
| >:You might be interested in the class sun.misc.Perf found in 1.4.2. It
.....
| From memory)
| >:I think something similar is likely to appear officially in 1.5.
....
| That might be useful. Trouble is, I don't know how to get *any*
| information on those undocumented classes sun.*. Got a pointer?

It came up recently in a discussion about
using the com.sun.tools.javac package..

Apparently Sun has not released the docs.
simply 'coz they do not want to encourage
folks to use classes that Sun may want to
move, deprecate or otherwise rearrange
later..

Personally I think they should release the
docs and warn you to use them 'at your
own risk' with no guarantees whatsoever
of forward compatibility..

[..and, like Mark, I'd heard Sun was
considering releasing the docs, but I
believe they still had not decided. ]

 

[Andrew Thompson]

"Andrew Thompson" ...
| "Steve W. Jackson" ...
....
| | That might be useful. Trouble is, I don't know how to get *any*
| | information on those undocumented classes sun.*. Got a pointer?
....
| Apparently Sun has not released the docs.

Oh, I forgot to add! Try Reflection for
a little information..

[ I am thinking of making a jar 'spider'.
You drop a jar into in and it would
use Reflection to create a Tree structure
the user can navigate around.
Wanders off, muttering vaguely.. ]

 

[Christophe Vanfleteren]

[ I am thinking of making a jar 'spider'.
You drop a jar into in and it would
use Reflection to create a Tree structure
the user can navigate around.
Wanders off, muttering vaguely.. ]

About every IDE out there has some widget that does that. It should be
pretty easy to use that code and make it work standalone.

 

[Steve W. Jackson]

:"Steve W. Jackson" ...
:| Mark Thornton wrote:
:...
:| >:You might be interested in the class sun.misc.Perf found in 1.4.2. It
:....
:| From memory)
:| >:I think something similar is likely to appear officially in 1.5.
:...
:| That might be useful. Trouble is, I don't know how to get *any*
:| information on those undocumented classes sun.*. Got a pointer?
:
:It came up recently in a discussion about
:using the com.sun.tools.javac package..
:
:Apparently Sun has not released the docs.
:simply 'coz they do not want to encourage
:folks to use classes that Sun may want to
:move, deprecate or otherwise rearrange
:later..
:
ersonally I think they should release the
:docs and warn you to use them 'at your
wn risk' with no guarantees whatsoever
f forward compatibility..
:
:[..and, like Mark, I'd heard Sun was
:considering releasing the docs, but I
:believe they still had not decided. ]
:
:--
:Andrew Thompson
:* http://www.PhySci.org/ PhySci software suite
:* http://www.1point1C.org/ 1.1C - Superluminal!
:* http://www.AThompson.info/andrew/ personal site

I looked in my local copy of the JavaDoc for 1.4.2, and it clearly warns
about the use of sun.* classes and how they're not guaranteed to work
across platforms, into the future, etc. So be it. When I visited the
Java 2 SDK FAQ, I saw the same question addressed, indicating that the
docs are in the source code for those packages available separately via
the Community Source Code Licensing site. I have no idea how large the
download is, but I'd rather not have to join there just to get it. It
would certainly be nice if they would do as you suggest -- make it
available but blast me with the caveats about why I shouldn't use it in
my application.

= Steve =

 

[Andrew Thompson]

| Andrew Thompson wrote:
|
| > [ I am thinking of making a jar 'spider'.
| > You drop a jar into in and it would
| > use Reflection to create a Tree structure
| > the user can navigate around.
| > Wanders off, muttering vaguely.. ]
|
| About every IDE out there has some widget that does that.

Huh? TextPad doesn't!
(laughs) OK, I realise you were not referring
to TextPad, but at the moment, my Eclipse
set-up is corrupt and I could not be bothered
fixing it.

| ..It should be
| pretty easy to use that code and make it work standalone.

Ehhh. (shrugs) By the time I'd got
the relevant code and teased it out
I could probably write my own.
Added advantage that I won't get
some lawyers turning up on the
doorstep suggesting I may have
encroached intellectual property..

[ And you probably meant 'use
opensource', but I am just trying
to justify why I should write my
own. ;-) ]