Incongruous CPU usage?

Ive written an alarm clock program which now function as it should. However, when I look at the process list in top, I see that the alarm program is using 100% of one of my processor cores capacity. I don't see cron using anywhere near that much processor capacity; is there a more economical way to check the current time than a loop?

Code:

do{
		time(&tmp);
	} while (tmp != timedata);

Yes, but it isn't going to be standard C. So what OS and compiler?

There is undoubtedly a system call you can use (such as sleep, or Sleep, or maybe even SlEeP) that will wait for a certain specified amount of seconds. Or if you want to get really fancy, you probably have a system call that will set an alarm using signals.

If this is on windows... code like that will race and eventually overheat the CPU as well as crippling multitasking... the windows function Sleep() is generally used to allow time sharing and other routines to run. You don't need to monitor tmp on a nanosecond basis... twice per second should be close enough...

Code:

#include <windows.h>


do
 { time(&tmp);
   Sleep(500); }
while (tmp != timedata);

... will probably result in a small fraction of a percent of CPU usage.

Linux has similar functions, but I'm not very familiar with them... Same on Mac.

Originally Posted by CommonTater

If this is on windows... code like that will race and eventually overheat the CPU... the windows function Sleep() is generally used to allow time sharing and other routines to run. You don't need to monitor tmp on a nanosecond basis... twice per second should be close enough...

It is an alarm clock, you wouldn't even need to check it that much. I would do a calculation to find out how far away the alarm is suppose to go off and then make an approach algorithm to use sleep(x) where x starts large and then decreases towards when the alarm was suppose to go off. That way you don't even need to check every 2 seconds or whatever.

Originally Posted by AndrewHunter

It is an alarm clock, you wouldn't even need to check it that much. I would do a calculation to find out how far away the alarm is suppose to go off and then make an approach algorithm to use sleep(x) where x starts large and then decreases towards when the alarm was suppose to go off. That way you don't even need to check every 2 seconds or whatever.

Well... just keeping it simple for the first timers... Your way would definately work better... but with Sleep(500) in there on a multicore CPU he's probably looking at .1 or .2% CPU usage, so it shouldn't be much of an issue.

Originally Posted by CommonTater

Well... just keeping it simple for the first timers... Your way would definately work better... but with Sleep(500) in there on a multicore CPU he's probably looking at .1 or .2% CPU usage, so it shouldn't be much of an issue.

Fair enough, it's not like I mentioned using interrupts or anything.....

Originally Posted by AndrewHunter

Fair enough, it's not like I mentioned using interrupts or anything.....

You been hanging around these DOS kiddies too long, my friend... it's warping your sense of values

AndrewHunter, an algorithm like that sounds a little bit out of my depth at the moment ; I will look into sleep system calls as CommonTater suggested. Im running FreeBSD 8.2 and I compile with gcc 4.5, by the way.

LOL.....that is actually showing my origins, I do admit though my first thought was thinking back to BIOS interrupts and TSR programs; however, I was actually referring to the SetTimer Windows API function.

EDIT: @OP: Using the sleep call would be the way to go.

Originally Posted by deadrabbit

AndrewHunter, an algorithm like that sounds a little bit out of my depth at the moment ; I will look into sleep system calls as CommonTater suggested. Im running FreeBSD 8.2 and I compile with gcc 4.5, by the way.

Some C libraries (usually time.h) include a non-standard delay() or sleep() function... or BSD may provide one as an API call.

The call to ... system("Sleep"); is *not* what you want...

Also... can you please change your avatar... There's some words we're not supposed to say here... George Carlin would be so proud!

Duly noted

Polling with a "sleep" function should be the absolute last thing considered. And in cases where you have no other choice, you should leave apologies in the code comments.

Calling sleep does allow your process to wait in the kernel - which is needed to prevent 100% CPU usage. The kernel then has to schedule your thread to run again, which involves a context switch and preempting what's currently running. This doesn't scale well. One process doing this may only consume 1% - but what if 100 or more need to be running?
If running on a portable device (laptop, phone) the system may need to transition out of a low-power state each time a thread needs to run, consuming battery life unnecessarily.

In general, don't "poll" if you don't have to. In this case, since we know exactly when we need to wake, ask the kernel to wake you at that time. A simple solution is to calculate the delta seconds and call sleep() once. Use nanosleep() if you need high resolution.

sleep
nanosleep

Note that signals can cause those functions to return early. Luckily, the return value is the amount of time you need to continue sleeping.

gg