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?
Originally Posted by anduril462
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
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...
... will probably result in a small fraction of a percent of CPU usage.Code:#include <windows.h> do { time(&tmp); Sleep(500); } while (tmp != timedata);
Linux has similar functions, but I'm not very familiar with them... Same on Mac.
Last edited by CommonTater; 08-14-2011 at 09:18 PM.
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.
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
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.....
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
You been hanging around these DOS kiddies too long, my friend... it's warping your sense of valuesFair enough, it's not like I mentioned using interrupts or anything.....
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.
Warning: Some or all of my posted code may be non-standard and as such should not be used and in no case looked at.
Some C libraries (usually time.h) include a non-standard delay() or sleep() function... or BSD may provide one as an API call.AndrewHunter, an algorithm like that sounds a little bit out of my depth at the moment
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
