Like Tree1Likes
  • 1 Post By BillyTKid

Delaying a program

This is a discussion on Delaying a program within the C Programming forums, part of the General Programming Boards category; I read about how you can use the for loop to delay a program's execution,but it's not really portable because ...

  1. #1
    Registered User
    Join Date
    Feb 2009
    Posts
    23

    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.?

  2. #2
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,047
    Tinkering with the computer's internal clock means coding it in assembly and that's going to be real portable

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,687
    >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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by 7h3_0r4c1_3 View Post
    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).

  5. #5
    Registered User
    Join Date
    Sep 2011
    Location
    Stockholm, Sweden
    Posts
    131
    Quote Originally Posted by CommonTater View Post
    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 View Post
    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.

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by iceaway View Post
    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]

  7. #7
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by iceaway View Post
    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.
    I dunno... but tight loops can end up driving the CPU to 100% usage... with the concomittant heat problem.
    Last edited by CommonTater; 10-03-2011 at 12:43 AM.

  8. #8
    Registered User
    Join Date
    Sep 2011
    Location
    Stockholm, Sweden
    Posts
    131
    Quote Originally Posted by CommonTater View Post
    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.

  9. #9
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by iceaway View Post
    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...

  10. #10
    Registered User
    Join Date
    Aug 2010
    Posts
    231
    Quote Originally Posted by Salem View Post
    ...

    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.
    Salem likes this.

  11. #11
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Quote Originally Posted by CommonTater View Post
    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.

    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.

  12. #12
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    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.
    Last edited by Adak; 10-03-2011 at 10:07 AM.

  13. #13
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,047
    Quote Originally Posted by BillyTKid View Post
    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.
    Last edited by itCbitC; 10-03-2011 at 11:00 AM.

  14. #14
    Programming Wraith GReaper's Avatar
    Join Date
    Apr 2009
    Location
    Greece
    Posts
    1,625
    Quote Originally Posted by CommonTater View Post
    Try it on Windows... you'll find out... It will bog the rest of the computer right down.
    Mine doesn't! It's dual core though...

    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... )
    Devoted my life to programming...

  15. #15
    Registered User Codeplug's Avatar
    Join Date
    Mar 2003
    Posts
    4,680
    >> 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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 1
    Last Post: 03-03-2009, 03:47 PM
  2. Replies: 2
    Last Post: 01-22-2008, 03:22 PM
  3. Replies: 5
    Last Post: 08-16-2007, 11:43 PM
  4. Replies: 18
    Last Post: 11-13-2006, 12:11 PM
  5. delaying for milli, microseconds
    By wazilian in forum C Programming
    Replies: 3
    Last Post: 10-23-2001, 01:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21