Resolution of WaitForSingleObject timers?

michael silva

unread,

Sep 5, 1997, 3:00:00 AM9/5/97

to

I came in late on a recent thread regarding timers with better
resolution than the normal 55 mS, and I didn't see any responses that
would generate a message ala WM_TIMER (if there is such a way I'd like
to hear about it). I was just thinking that I could simulate such a
mechanism by having a thread that has WaitForSingleObject wait on an
object that's never signaled, but with a timeout value, and use the
timeout to generate a message. This would only be worth doing if the
timeout timer has better resolution, so does anybody know if this is
the case? Thanks.

Mike

Felipe Martins

unread,

Sep 5, 1997, 3:00:00 AM9/5/97

to

Three points:
1) You could simply call Sleep(dwTimeMillisecs) to suspend your thread for some
amount of time, no need to use WaitForSingleObject.
2) I don't think this timing procedure is meant to be accurate. Their main use
is to aid in thread synchronization.

mjs...@ix.netcom.com(michael silva) wrote:

--
Felipe Martins
Department of Mathematics
Cleveland State University
fmar...@math.csuohio.edu

michael silva

unread,

Sep 5, 1997, 3:00:00 AM9/5/97

to

In <340fc55...@news.csuohio.edu> fmar...@math.csuohio.edu (Felipe

Martins) writes:
>
>Three points:
>1) You could simply call Sleep(dwTimeMillisecs) to suspend your thread
>for some amount of time, no need to use WaitForSingleObject.
>2) I don't think this timing procedure is meant to be accurate. Their
>main use is to aid in thread synchronization.

I did a small experiment and determined that the resolution is indeed
better than 55 mS (1000 waits at 10mS came out to 10 seconds).
Regarding the use of Sleep() rather than WaitForSingleObject(), I
explained myself badly -- I would use the waited-on object to end the
timer thread, but in the meantime it would loop and post a message
every timeout. By making the timer thread high priority (OK since it
will be waiting 99.9% of the time) it looks like I'll get the results I
need.

dave porter

unread,

Sep 5, 1997, 3:00:00 AM9/5/97

to

Yes. In particular, your thread doesn't necessarily get to run after
the timeout has elapsed, it merely gets to be runnable. Normal
scheduling rules determine what will run.

I'm not sure where this 55mS comes from though. I thought on
NT at least that timers were serviced every 10mS tick. It's a trivial
experiment to try, though.

dave
--
for email: remove the 'z' from my address. sorry.

Felipe Martins <fmar...@math.csuohio.edu> wrote in article
<340fc55...@news.csuohio.edu>...

> Three points:
> 1) You could simply call Sleep(dwTimeMillisecs) to suspend your thread
for some
> amount of time, no need to use WaitForSingleObject.
> 2) I don't think this timing procedure is meant to be accurate. Their
main use
> is to aid in thread synchronization.
>

Vincent Goossens

unread,

Sep 9, 1997, 3:00:00 AM9/9/97

to

Prefer using SleepEx(time_in_ms,FALSE) because Sleep() returns immediately
if there are no other threads of equal priority ready to run.

--
Vincent Goossens goos...@epc.be
European Peripheral Corp.

Dave Thompson

unread,

Sep 9, 1997, 3:00:00 AM9/9/97

to

This is false. The SDK documentation is a little strange where it says:

Parameters
dwMilliseconds
Specifies the time, in milliseconds, for which to suspend execution. A
value of zero causes the thread to relinquish the remainder of its time
slice to any other thread of equal priority that is ready to run. If there
are no other threads of equal priority ready to run, the function returns
immediately, and the thread continues execution. A value of INFINITE causes
an infinite delay.

But, if the dwMill.. is zero AND "no other threads..." then it continues (
Instead of releasing the remaining time slice). A Sleep(1000) will always
sleep about a second.

Anyone who really knows exactly how Sleep(1000) and SleepEx(1000,FALSE) are
different please respond (no speculation please).

Vincent Goossens <goos...@epc.be> wrote in article
<01bcbcf4$fc879f80$530226c3@vgopc>...