Run code for x amount of time

Question

To preface, I am on a Unix (linux) system using gcc.

What I am stuck on is how to accurately implement a way to run a section of code for a certain amount of time.

Here is an example of something I have been working with:

struct timeb start, check;
int64_t duration = 10000;
int64_t elapsed = 0;

ftime(&start);

while ( elapsed < duration ) {
    // do a set of tasks
    ftime(&check);
    elapsed += ((check.time - start.time) * 1000)  + (check.millitm - start.millitm);
}

I was thinking this would have carried on for 10000ms or 10 seconds, but it didn't, almost instantly. I was basing this off other questions such as How to get the time elapsed in C in milliseconds? (Windows) . But then I thought that if upon the first call of ftime, the struct is time = 1, millitm = 999 and on the second call time = 2, millitm = 01 it would be calculating the elapsed time as being 1002 milliseconds. Is there something I am missing?

Also the suggestions in the various stackoverflow questions, ftime() and gettimeofday(), are listed as deprecated or legacy.

I believe I could convert the start time into milliseconds, and the check time into millseconds, then subtract start from check. But milliseconds since the epoch requires 42 bits and I'm trying to keep everything in the loop as efficient as possible.

What approach could I take towards this?

Answer 1

Code is incorrect calculating elapsed time.

// elapsed += ((check.time - start.time) * 1000)  + (check.millitm - start.millitm);
elapsed = ((check.time - start.time) * (int64_t)1000)  + (check.millitm - start.millitm);

---

There is some concern about check.millitm - start.millitm. On systems with struct timeb *tp, it can be expected that the millitm will be promoted to int before subtraction occurs. So the difference will be in the range [-1000 ... 1000].

       struct timeb {
           time_t         time;
           unsigned short millitm;
           short          timezone;
           short          dstflag;
       };

---

IMO, more robust code would handle ms conversion in a separate helper function. This matches OP's "I believe I could convert the start time into milliseconds, and the check time into millseconds, then subtract start from check."

int64_t timeb_to_ms(struct timeb *t) {
  return (int64_t)t->time * 1000 + t->millitm;
}

struct timeb start, check;
ftime(&start);
int64_t start_ms = timeb_to_ms(&start);

int64_t duration = 10000 /* ms */;
int64_t elapsed = 0;

while (elapsed < duration) {
  // do a set of tasks
  struct timeb check;
  ftime(&check);
  elapsed = timeb_to_ms(&check) - start_ms;
}

Answer 2

If you want efficiency, let the system send you a signal when a timer expires.

Traditionally, you can set a timer with a resolution in seconds with the alarm(2) syscall.

The system then sends you a SIGALRM when the timer expires. The default disposition of that signal is to terminate.

If you handle the signal, you can longjmp(2) from the handler to another place.

I don't think it gets much more efficient than SIGALRM + longjmp (with an asynchronous timer, your code basically runs undisturbed without having to do any extra checks or calls).

Below is an example for you:

#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>

static jmp_buf jmpbuf;

void hndlr();
void loop();
int main(){

    /*sisv_signal handlers get reset after a signal is caught and handled*/
    if(SIG_ERR==sysv_signal(SIGALRM,hndlr)){
        perror("couldn't set SIGALRM handler");
        return 1;
    }

    /*the handler will jump you back here*/
    setjmp(jmpbuf);

    if(0>alarm(3/*seconds*/)){
        perror("couldn't set alarm");
        return 1;
    }

    loop();

    return 0;
}

void hndlr(){
    puts("Caught SIGALRM");
    puts("RESET");
    longjmp(jmpbuf,1);
}

void loop(){
    int i;
    for(i=0;  ; i++){
        //print each 100-milionth iteration
        if(0==i%100000000){
            printf("%d\n", i);
        }
    }
}

If alarm(2) isn't enough, you can use timer_create(2) as EOF suggests.