java.begginer
java.begginer

Reputation: 59

What is the efficient way to continuously check until a condition is true

So I have this program that continuously check until the condition is true. My problem is whenever I run it, my computer slows down because of the loop. Can anyone please suggest the best and most efficient way to do this? Thank you for your response in advance. To illustrate my problem, here is a code that represents it:

#include <stdio.h>
#include <time.h>
#include <string.h>
#include <windows.h>

int main(void){
    time_t now;
    struct tm *local;
    while(1){
        time(&now);
        local = localtime(&now);

        if(local->tm_min > 55){
            printf("Time:\t%d:%d:%d\n",local->tm_hour,local->tm_min,local->tm_sec);
            getch();
            exit(0);
        }
    }

    return 0;
}

Upvotes: 1

Views: 1414

Answers (2)

Efficiently? One way or the other you need to put your process to sleep until the condition WILL BE TRUE - then wake up and die (so to speak :-). Since your code includes windows.h I'll assume you're running on Windows and thus have the Sleep() function available.

#include <stdio.h>
#include <windows.h>
#include <time.h>

int main(void)
  {
  time_t now;
  struct tm *local;
  DWORD msecs;

  time(&now);
  local = localtime(&now);

  /* (55 * 60000) = msecs in 55 minutes */
  msecs = (55 * 60000) - ((local->tm_min * 60000) + (local->tm_sec * 1000));

  if(msecs > 0)
    Sleep(msecs)    

  return 0;
  }

Upvotes: 1

If polling is really what you want, or you have to use it, then you must give breath to the system by using sleep's.

So, how much to sleep in each iteration? It can be a fixed value (and if you sleep just 1 millisecond you will be stunned at how this is effective). A fixed value, say 20-30 milliseconds is good if you check for slow events like keystrokes by a real user. If, say, you are monitoring a serial port, perhaps you need lower values.

Then, depending on the application, you can also implement a variable sleep time. For example (this is a little stupid but it is just to explain): you wait for keystrokes, and sleep 30 milliseconds. Then you use your program in a pipe and discover that it is painly slow. A solution could be to set the value to sleep equal to 30 ms, but after having read a character, the value is lowered to 0 which causes the sleep to be not performed. Every time the condition fails the value is raised up to the maximum limit (20-30 milliseconds for a keyboard).

-- EDIT AFTER COMMENTS --

It has pointed out that keyboards and serial ports do not need polling, or they should not be polled. Generally speaking this is true, but it depends on the hardware and operating system (which in turn is a piece of software and, if the hardware does not support an interrupt for a given condition, even the OS would have to poll). About keyboards, for example, I thought at those little ones implemented as a matrix of buttons: some small CPUs have special facilities to generate an interrupt on any I/O change, but other don't: in that case polling is the only solution - and it is also ideal for implementing anti-bouncing (this kind of polling is not necessarily performed inside a loop).

For serial ports, it is almost true that nobody would implement one without an interrupt (to avoid polling). But even so, it is difficult to manage the incoming data in an event-driven fashion; often a flag is set, and some other part of the program, which polls that flag, will work out the message.

Event-driven programming seems easy at first, but as soon the program gets bigger the complication augments too.

There are other situations to consider, for example loops which read data from somewhere and process those data. If something else has to be done inside the loop, for example checking how much time is passed, but the reading is blocking, the reading must be implemented in a non-blocking way, and the whole loop must turn into a kind of polling for one or more conditions -unless one uses multi-threading.

Anyway, I agree that polling is evil and should only be used when necessary.

Upvotes: 2

Related Questions