Oh, sorry I wasn't more clear. I'm used to Java which is why I mention
the sleep function, like Thread.sleep() from the Java API. For whatever
thread library you're using, such as pthreads, there is a corresponding
sleep function. It might be called usleep or have some other name, but
it does the same thing. It causes ONLY one thread to sleep, and the
rest of the threads in the process keep going like normal.
So, one thread can be only responsible for updating the timer, which is
really just a variable it keeps incrementing, and then all the other
threads can poll the timer variable, without hanging the whole process.
You are right that a heavily loaded system may cause the thread that's
performing the updates to be a little slower. So if it sleeps for one
second it might actually sleep for 1.1 seconds. However, this
limitation is a general limitation to ANY application for ANY way you
keep timings.
If you want an application to do something EXACTLY at 30 second
intervals, then your application must be run on what is known as a
real-time operating system. Common versions of Linux are not real time,
as well as windows, and pretty much every other common OS. There
probably is some versions of real time Linux out there . In short, real
time operating systems guarantee that events are done within an exact
amount of time. These are important for devices such as cars. If you
hit the brake, you don't want the car to wait 2 seconds and then brake,
you want it to brake immediately. So, they have real time operating
systems to guarantee when things will be done.
But the operating systems we use only guarantee MINIMUM times. If my
thread sleeps for one second, it's guaranteed to sleep for at least one
second, but it's not guaranteed to sleep exactly one second. It might
sleep more.
Regards,
Warren
-----Original Message-----
From: Cole Tuininga [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 31, 2001 7:37 AM
To: Mansur, Warren
Subject: Re: C Question
On Mon, Jul 30, 2001 at 07:30:39PM -0500, Mansur, Warren wrote:
> One idea is to have another thread running that keeps time for you.
You
> just call sleep(x), where x is the level of granularity you want your
> timer to have in your thread, and then add 1 to your time variable
each
> time the thread wakes up. You can have another function that polls
the
> value of your time variable. The getting and setting functions for
the
> time variable can have a mutex lock.
This is a similar approach to the one mentioned by Pete, with the
similar problem of a loaded CPU messing up the timing.
Additionally, as this is going to be a threaded app soon, I can't
make use of sleep.
For the folks that are unaware, the way sleep(x) works (as far as I
know - please feel free to correct me) is that it schedules a SIGALRM
to occur in x seconds and then sleeps the process. When the SIGALRM is
received, it wakes the process up and continues it on it's merry way.
Within a threaded application, you have no guarrantee as to which thread
is going to receive that signal. Additionally (and I'm just assuming
here, I don't know this for a fact) when you call sleep(x) from within
a threaded app, in an OS that is not inherently threaded (linux, for
instance) the entire process (not just the calling thread) is put into
sleep mode.
--
"Things are fine, the upcoming semester approaches like a brick wall
and we're in a 1962 Corvair with no brakes." - Paul Sand
Cole Tuininga
Network Admin
Code Energy, Inc
[EMAIL PROTECTED]
(603) 766-2208
PGP Key ID: 0x43E5755D
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
