Delaying a program

I read about how you can use the for loop to delay a program's execution,but it's not really portable because the processors might run them differently based on their performance.

C's in built sleep() function was also said to not be portable because quote from a book:

"Note that in some implementations of GCC, the sleep() function apparently uses millisec..onds, not seconds, as its argument."

So that leave me with using the computers internal clock to time a delay,which the book also suggested,but didn't explain.

So my question is,where can I found out more about it,like what files I have to include for it to work etc.?

Tinkering with the computer's internal clock means coding it in assembly and that's going to be real portable ;)

>C's in built sleep() function was also said to not be portable because quote from a book:
> "Note that in some implementations of GCC, the sleep() function apparently uses millisec..onds, not seconds, as its argument."
You should probably get a better book then.
"apparently" is not a well reasoned argument for doing or not doing something.

Or perhaps the author is merely dyslexic, and can't tell the difference between sleep(), which is ISO-C, and takes seconds, and Sleep(), which is Win32, and takes milliseconds.

Quote:

---

Originally Posted by 7h3_0r4c1_3

I read about how you can use the for loop to delay a program's execution,but it's not really portable because the processors might run them differently based on their performance.

C's in built sleep() function was also said to not be portable because quote from a book:

"Note that in some implementations of GCC, the sleep() function apparently uses millisec..onds, not seconds, as its argument."

So that leave me with using the computers internal clock to time a delay,which the book also suggested,but didn't explain.

So my question is,where can I found out more about it,like what files I have to include for it to work etc.?

---

Also let me toss in a note of caution here...

Code:

---

int i = 0;
while(i++ < 100000000);

---

This is what we call a tight loop. Basically it's just running around counting and not doing much else. In some cases it may also include some minimal processing such as decrementing a number without calling an external function... but it's still a very tight loop.

Loops like this can race the CPU to 100% usage which can cause overheating problems. They also don't release time slices which may cause multitasking problems.

This is where sleep() and the windows Sleep() come in ...

Code:

---

int i = 0;
while (i++ < 10000000)
  Sleep(0);

---

This prevents the CPU race condition and allows multitasking to continue normally.

If you are just wanting a time delay... a simple hesitation... Use sleep(seconds) or #include <windows.h> and use Sleep(miliseconds).

Quote:

---

Originally Posted by CommonTater

Also let me toss in a note of caution here...

Code:

---

int i = 0;
while(i++ < 100000000);

---

This is what we call a tight loop. Basically it's just running around counting and not doing much else. In some cases it may also include some minimal processing such as decrementing a number without calling an external function... but it's still a very tight loop.

Loops like this can race the CPU to 100% usage which can cause overheating problems. They also don't release time slices which may cause multitasking problems.

---

AFAIK unless one is running some kind of real-time kernel without preemption and interrupts disabled, the scheduler will multitask just fine despite the "tight loop". But please correct me if I am wrong :)

Quote:

---

Originally Posted by CommonTater

This is where sleep() and the windows Sleep() come in ...

Code:

---

int i = 0;
while (i++ < 10000000)
  Sleep(0);

---

This prevents the CPU race condition and allows multitasking to continue normally.

If you are just wanting a time delay... a simple hesitation... Use sleep(seconds) or #include <windows.h> and use Sleep(miliseconds).

---

Is "race condition" commonly used to describe this scenario? I have only heard race condition used when it comes to concurrent access to data and such.

Quote:

---

Originally Posted by iceaway

AFAIK unless one is running some kind of real-time kernel without preemption and interrupts disabled, the scheduler will multitask just fine despite the "tight loop". But please correct me if I am wrong :)

---

Try it on Windows... you'll find out... It will bog the rest of the computer right down.

Windows is cooperative multitasking, only drivers are interrupt driven... If you do something that doesn't release a timeslice, you're going to affect everything running in userspace...





Is "race condition" commonly used to describe this scenario? I have only heard race condition used when it comes to concurrent access to data and such.[/QUOTE]

Quote:

---

Originally Posted by iceaway

AFAIK unless one is running some kind of real-time kernel without preemption and interrupts disabled, the scheduler will multitask just fine despite the "tight loop". But please correct me if I am wrong :)

---

Try it on Windows... you'll find out... It will bog the rest of the computer right down.

Windows is cooperative multitasking, only drivers are interrupt driven... If you do something that doesn't release a timeslice, you're going to affect everything running in userspace...

Quote:

---

Is "race condition" commonly used to describe this scenario? I have only heard race condition used when it comes to concurrent access to data and such.

---

I dunno... but tight loops can end up driving the CPU to 100% usage... with the concomittant heat problem.

Quote:

---

Originally Posted by CommonTater

Try it on Windows... you'll find out... It will bog the rest of the computer right down.

Windows is cooperative multitasking, only drivers are interrupt driven... If you do something that doesn't release a timeslice, you're going to affect everything running in userspace...

---

So you are saying that user space applications in windows must specifically "yield()" the processor to allow multitasking? I thought that was something of the ancient past.

Quote:

---

Originally Posted by iceaway

So you are saying that user space applications in windows must specifically "yield()" the processor to allow multitasking? I thought that was something of the ancient past.

---

Tight loops are an exceptional case... Normally time slices are yielded and allocated when functions return, that is you write a function that takes 10ms and when the function returns some other app gets it's turn. However in a tight loop there's no function returning... thus no yeilded time slice. If you write a loop that just races around itself for 20 seconds, you'll see the effect but you'll also heat up your CPU pretty good in the process.

MS has gotten a lot better with this, but, no it's not a thing of the past. Part of the sluggishness you may observe in other threads and processes is because the CPU is being maxed out, part will be due to processes holding on to time slices...

Quote:

---

Originally Posted by Salem

...

Or perhaps the author is merely dyslexic, and can't tell the difference between sleep(), which is ISO-C, and takes seconds, and Sleep(), which is Win32, and takes milliseconds.

---

Wrong.
There is no sleep in C, sleep/nanosleep is only POSIX 1003.1(b) and Sleep is WinAPI.
Only clock/clock_t is C standard, but a sleep-function with clock() is always a busy loop.

Quote:

---

Originally Posted by CommonTater

Windows is cooperative multitasking, only drivers are interrupt driven... If you do something that doesn't release a timeslice, you're going to affect everything running in userspace...

---

Windows has never been cooperative multitasking for anything other than 16-bit apps on DOS lineage versions. And the last one of those was 11 years ago. It was, but hardly is.

Quote:

---

Try it on Windows... you'll find out...

---

Is this what Pelles means by optimizing compiler? No compiler worthy of the tag will leave an empty busy loop in the assembly.

Pelles C compiler will allow _sleep(seconds), if you include time.h, but it's not standard C, it says.

Useless loops are optimized and not executed with Pelles C, in very limited testing.

Sleep(milliseconds), is OK, with windows.h included, or if you use the /Go option.

And yes, in Windows, tight loops will keep a system busy, but only if you run the program with normal priority. Use lower priority, and 100% utilization of all cores, doesn't cause a problem. Use aftermarket heat sinks to handle the extra heat. I run my PC's that way, all the time, 24/7, <shameless plug> as part of drug and disease research projects (and sometimes clean water and clean energy), for Folding@Home (Stanford), World Community Grid (Scripps Research), or Rosetta (University of Washington).

The trick is, they run at idle priority, and yield to everything else, very quickly that are running at a higher priority.

Quote:

---

Originally Posted by BillyTKid

Wrong.
There is no sleep in C, sleep/nanosleep is only POSIX 1003.1(b) and Sleep is WinAPI.
Only clock/clock_t is C standard, but a sleep-function with clock() is always a busy loop.

---

IBTD, sleep() was part of the original C, K&R1 and 2 and is part of the ISO C standard too. Only thing that restricts portability is that in the good ol' days, max argument to sleep() <= 65535 because an unsigned int was only 16 bits wide. Nowadays an unsigned int is at least 32 bits wide, so portability comes into play when moving from a new system to a much older one. How many times that's going to happen? Probably zero as those machines are more or less extinct.

Quote:

---

Originally Posted by CommonTater

Try it on Windows... you'll find out... It will bog the rest of the computer right down.

---

Mine doesn't! :p It's dual core though... :D

Speaking more generally, for newer CPUs with multiple cores, the usage of the core the program is mounted on will most certainly maximize.
( And before long I wondered why a tight loop uses only 50% of my CPU... :D:D:D )

>> the scheduler will multitask just fine despite the "tight loop". But please correct me if I am wrong
You are correct.

>> The trick is, they run at idle priority, and yield to everything else, very quickly that are running at a higher priority.
In addition, even if running at normal priority, the OS will still schedule other threads to run on the same core. The only difference is that the tight-loop thread is using 100% of its time-slice and is always in a ready-to-run state. Just because task manager may show "100%" cpu usage (or 50% for hyper-threaded cores), that doesn't mean that the OS isn't scheduling everything else in the system just like it normally would. If you have a slow single-core cpu, then a busy-loop is more likely to cause a noticeable performance decrease in the rest of the OS.

Running a busy-loop at idle priority works well with a "preemptive multitasking" OS, since the scheduler will "preempt" a lower priority thread in the middle of it's time-slice if a higher priority thread is in a ready-to-run state.

Also, "Sleep(0)" only yields to threads in the ready-to-run state with the same or higher priority. So if your busy-loop is the lone high priority thread in the system, it will still show 100% cpu usage.

>> sleep() ... is part of the ISO C standard too.
"ISO C" typically refers to the normal C standards - C89/C90 and C99. Neither contain sleep(). It is in the Posix standard, as mentioned.

gg