How to maintain time in a C program

[Haneef]

Hi All

The problem is that I need to keep track of time in my program.

Getting time using system calls every time I need is definitely very
expensive.

So one solution could be to spawn a thread and keep incrementing the
time. But I dont want another thread just to maintain the time.

Please let me know if you have any other solutions. Any Links also
would be helpful.

Thanks in advance,
Haneef

 

[santosh]

Hi All

The problem is that I need to keep track of time in my program.

Getting time using system calls every time I need is definitely very
expensive.

How do you come to this conclusion. Have you measured and found system calls
to be unacceptably slow? Except in unusual circumstances, an ordinary
program should get it's time from the system. Keeping time itself,
especially in an interrupt based, multitasking system is likely to lead to
erroneous results. The system on the other hand has the help of the
hardware and almost certain to do a better job.

So one solution could be to spawn a thread and keep incrementing the
time. But I dont want another thread just to maintain the time.

Keep incrementing time? How exactly? Do you want calender time or processor
time? What about the time when your thread is inactive?

Please let me know if you have any other solutions. Any Links also
would be helpful.

I think you are searching for a solution in search of a problem. Just use
Standard C functions like time or clock. If, after a trial, you deem them
inappropriate or otherwise unsuitable, the underlying system may provide
better APIs. Consult the system's documentation or a group for it.

 

[Haneef]

How do you come to this conclusion. Have you measured and found system calls
to be unacceptably slow? Except in unusual circumstances, an ordinary
program should get it's time from the system. Keeping time itself,
especially in an interrupt based, multitasking system is likely to lead to
erroneous results. The system on the other hand has the help of the
hardware and almost certain to do a better job.

I am talking about the calendar time. Its just that time is to be used
so many times(not to mention at different points of time) that system
call would be expensive. So many calls when only one can suffice is
definitely not recommended.

Keep incrementing time? How exactly? Do you want calender time or processor
time? What about the time when your thread is inactive?

The solution I know as of now is to have a thread and initialize a
global variable with current time and keep incrementing the global
variable and sleep for the remaining time. In this case its just
utilizing the resources without much use.

I think you are searching for a solution in search of a problem. Just use
Standard C functions like time or clock. If, after a trial, you deem them
inappropriate or otherwise unsuitable, the underlying system may provide
better APIs. Consult the system's documentation or a group for it.

Hey, I am just a newbie.

 

[santosh]

I am talking about the calendar time. Its just that time is to be used
so many times(not to mention at different points of time) that system
call would be expensive. So many calls when only one can suffice is
definitely not recommended.

Unless time and difftime actually prove to be a bottleneck, (found by
profiling), I'd recommend you use them.

If you don't mind sacrificing portability the consider sleeping for a set
period of time using setitimer or alarm. However signals can mess up the
calculation here. Another non-portable option is gettimeofday.

The solution I know as of now is to have a thread and initialize a
global variable with current time and keep incrementing the global
variable and sleep for the remaining time. In this case its just
utilizing the resources without much use.

This method is probably overkill, error prone, and is very likely to involve
as many, if not more, system calls than getting the time directly whenever
you want it. Also interaction between multiple threads and global variables
need to be carefully kept track of.

<snip>

 

[santosh]

Unless time and difftime actually prove to be a bottleneck, (found by
profiling), I'd recommend you use them.

If you don't mind sacrificing portability the consider sleeping for a set
period of time using setitimer or alarm.

The above is wrong. setitimer and alarm do not put the process to sleep but
interrupt it after the specified interval.

<snip>

 

[Haneef]

Someone please let me know "How can I keep track or maintain time in
my program" ?

 

[Martien verbruggen]

Someone please let me know "How can I keep track or maintain time in
my program" ?

You haven't exactly explained what was wrong with the answers that you
already got.

In what way was that not what you were looking for? Could you maybe be a
bit more clear? Are you maybe looking for time, localtime(), mktime()
and strftime()?

Without you being more specific and clear about exactly what it is
you're trying to do, and what exactly you're doing when you talk about
"system calls". I doubt anyone can give you more help.

Martien

 

[Mark McIntyre]

I am talking about the calendar time. Its just that time is to be used
so many times

Why? This sounds like a design flaw.

(not to mention at different points of time) that system
call would be expensive.

Yes, but have you actually /measured/ this, to prove it is a real
problem? Bear in mind that many many real applications out in the real
world use timestamps, and its generally isn't an issue.

So many calls when only one can suffice is
definitely not recommended.

It might *feel* like a bad idea, but you don't seem to have any
evidence that it really is. Remember the Three Laws of Optimisation.

Hey, I am just a newbie.

Thats ok.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Someone please let me know "How can I keep track or maintain time in
my program" ?

You won't get more help by asking the same quesiton twice and ignoring
all the answers you got the first time.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Thad Smith]

The problem is that I need to keep track of time in my program.

Getting time using system calls every time I need is definitely very
expensive.

The acceptability of the execution time depends on your timing
constraints. How often does your application need to check the time?
How did you arrive at that interval? How long does it take for a system
call on your target system to return the time?

Most desktop applications should work fine with standard system time
routines. Real-time applications can have tighter constraints. I have
written applications that directly read a timer register for short time
interval measurements, but they required execution time of a few
microseconds on slow 8-bit processors.

Try the simplest approach first, using standard functions. If you think
that is a significant bottleneck measure the cost, determine the impact,
and evaluate the alternatives. You may be thinking of obtaining the
system time more often than you need.

 

[Chris Hills]

Hi All

The problem is that I need to keep track of time in my program.

Getting time using system calls every time I need is definitely very
expensive.

So one solution could be to spawn a thread and keep incrementing the
time. But I dont want another thread just to maintain the time.

Please let me know if you have any other solutions. Any Links also
would be helpful.

It largely depends on your target environment.

 

[Mike Wahler]

Hi All

The problem is that I need to keep track of time in my program.

Getting time using system calls every time I need is definitely very
expensive.

How do you know? Did you measure? If not, then you do NOT know.

So one solution could be to spawn a thread and keep incrementing the
time.

Perhaps. But then you also introduce additional complexity,
perhaps unnecessarily.

But I dont want another thread just to maintain the time.

I would not either.

Please let me know if you have any other solutions.

I would first use the simplest solution (i.e. the standard library),
and only if profiling proved it unacceptable, would I seek another.

If I did prove there's a performance issue, I'd then look to the
host operating system facilites, as they'd be most likely be
optimized for the target environment.

-Mike