Program runs choppy

I have a piece of code which is just a simple printf statement followed by a usleep command. Then it is just looped.

I am running this on solaris 8, and what happens is a bunch of output will come up like 15 at a time, then it will pause for a moment (longer than the usleep) and then spit out another block of output?

If anyone could help me that would be awesome.

Nick

If anyone could post the code that you're talking about, that would be awesome.

Code:

---

#include <unistd.h>
#include <stdio.h>

#define MAX 250

int main()
{
    int a=0;
    while(a<=MAX)
    {printf("2\n");
    usleep(500);
    a++;}
   
    return 0;
}

---

The program isn't flushing the output before each sleep. Try putting an fflush(stdout); after the print statement.

It is still doing the same thing, I think it may have something to do with the scheduling on the unix box, since things are being run in round robin format, could it have to do with the shares, it runs all it can in its time quantum, and then if forced to wait.

The only thing that causes me to doubt this theory is that it is the only process running on the box, but the pause could come from it waiting to see if its turn has come up again.

Examing it more carefully and experimenting with the the value of the usleep, I have found that changing the value changes the amount of times it runs through before a longer pause

Well what on earth did you think usleep did?


Quzah.

Haha, that came out wrong.

It means instead of

1
2
3
4
5
Long Pause (longer than usleep)

its
1
2
3
Long Pause

usleep() has a granularity of 18.2 milliseconds. (It calls time().) So sometimes the paused time is rounded.

try system(sleep x); (stdlib.h)

or the regular sleep(); (cant remember which header)
but on non win systems... you can take advantage of the build in sleep function.

Quote:

---

Originally Posted by faze

try system(sleep x);

---

You mean, of course, system ("sleep x"); But I don't know if that would help, unless Smartiepants586 wants to have a really large pause. Sleep can only "sleep" for one second or more, while he is experimenting with milliseconds. But, anyway, it's worth a shot.

All 'sleep's are voluntary requests to the system, the system is in no way obligated to ensure that the program wakes up after the given amount of time. If the system is busy doing something else (perhaps something with a higher priority) then the program can be on hold for substantially longer than the requested amount. The only obligation I am aware of is that the system will sleep the program at least as long as the requested amount, rounded up to the nearest timeslice.

There are a few schedulers that automatically 'nice' programs once in a while to give lower priority programs a chance (typically the scheduler does round robin WITHIN the same priority), you may be experiencing that.