Delay in C on linux or OSS

[Ashraf Fouad]

Dears,
    I'm writing C application using native compiler /usr/bin/c89 to
run under OSS environment or linux. I would like to implement delay
in
milliseconds. Does anyone know what is the best way to do this?

Thanks in advance.

 

[Dann Corbit]

(e-mail address removed)>, (e-mail address removed)
says...

Dears,
    I'm writing C application using native compiler /usr/bin/c89 to
run under OSS environment or linux. I would like to implement delay
in
milliseconds. Does anyone know what is the best way to do this?

From the C-FAQ:

19.37: How can I implement a delay, or time a user's response,
with sub-second resolution?

A: Unfortunately, there is no portable way. Routines you might
look for on your system include clock(), delay(), ftime(),
gettimeofday(), msleep(), nap(), napms(), nanosleep(),
setitimer(), sleep(), Sleep(), times(), and usleep().
(A function called wait(), however, is at least under Unix *not*
what you want.) The select() and poll() calls (if available)
can be pressed into service to implement simple delays.
On MS-DOS machines, it is possible to reprogram the system timer
and timer interrupts.

Of these, only clock() is part of the ANSI Standard. The
difference between two calls to clock() gives elapsed execution
time, and may even have subsecond resolution, if CLOCKS_PER_SEC
is greater than 1. However, clock() gives elapsed processor
time used by the current program, which on a multitasking system
may differ considerably from real time.

If you're trying to implement a delay and all you have available
is a time-reporting function, you can implement a CPU-intensive
busy-wait, but this is only an option on a single-user, single-
tasking machine, as it is terribly antisocial to any other
processes. Under a multitasking operating system, be sure to
use a call which puts your process to sleep for the duration,
such as sleep() or select(), or pause() in conjunction with
alarm() or setitimer().

For really brief delays, it's tempting to use a do-nothing loop
like

long int i;
for(i = 0; i < 1000000; i++)
;

but resist this temptation if at all possible! For one thing,
your carefully-calculated delay loops will stop working properly
next month when a faster processor comes out. Perhaps worse, a
clever compiler may notice that the loop does nothing and
optimize it away completely.

References: H&S Sec. 18.1 pp. 398-9; PCS Sec. 12 pp.
197-8,215-6; POSIX Sec. 4.5.2.

 

[FredK]

(e-mail address removed)>, (e-mail address removed)
says...

For really brief delays, it's tempting to use a do-nothing loop
like

long int i;
for(i = 0; i < 1000000; i++)
;

An optimizing compiler may remove the loop. Make i volatile or have the
loop do something interesting in the loop.

 

[Dann Corbit]

An optimizing compiler may remove the loop. Make i volatile or have the
loop do something interesting in the loop.

It is always good to read the message before responding.

 

[Jens Thoms Toerring]

An optimizing compiler may remove the loop. Make i volatile or have the
loop do something interesting in the loop.

But that doesn't address the second problem mentioned in the FAQ,
i.e. that the execution time and thus the delay achieved still
depends on the hardware this is running on. So using a proper
system-specific function (like the ones listed in the FAQ, e.g.
nanosleep() on POSIX systems, Sleep() under Windows etc.) is
probably a safer bet.
Regards, Jens

 

[Seebs]

Dears,
? ? I'm writing C application using native compiler /usr/bin/c89 to
run under OSS environment or linux. I would like to implement delay
in
milliseconds. Does anyone know what is the best way to do this?

Many people know! They know the best ways to do it in various different
contexts.

Long story short: There is not a particularly "best" generic C way to do
this. There are many exceptionally bad ways. Most specific real environments
will provide a reasonably good way to do this, or possibly several reasonably
good ways to do this. A real answer depends on the environment you're
in.

It sounds like Linuxy stuff, but "OSS environment or linux" is confusing,
and the Linux systems I use have not usually considered anything called
"c89" to be the "native compiler". If you're looking for something that works
on user-mode code on a Unix system, try comp.unix.programmer.

-s

 

[Keith Thompson]

An optimizing compiler may remove the loop. Make i volatile or have the
loop do something interesting in the loop.

Your suggesting an improvement for a technique that almost certainly
shouldn't be used in the first place.

 

[Keith Thompson]

It sounds like Linuxy stuff, but "OSS environment or linux" is confusing,
and the Linux systems I use have not usually considered anything called
"c89" to be the "native compiler". If you're looking for something that works
on user-mode code on a Unix system, try comp.unix.programmer.

On my system (Ubuntu 9.04), "c89" is essentially a wrapper for
"gcc -std=c89". There's a similar "c99" which is a wrapper for
"gcc -std=c99".

 

[Kenny McCormack]

Your suggesting an improvement for a technique that almost certainly
shouldn't be used in the first place.

Aren't you even going to point out the obvious fact - that the code
above is the only standards compliant way to do it (*) and thus *is* the
CLC-recommended way to do it.

(*) With, of course, the volatile declaration - can't forget that, Oh no.

 

[Alan Curry]

On my system (Ubuntu 9.04), "c89" is essentially a wrapper for
"gcc -std=c89". There's a similar "c99" which is a wrapper for
"gcc -std=c99".

POSIX requires a program called "c99", which "shall accept source code
conforming to the ISO C standard." For GNU/Linux distributors, the easiest
way to comply is with that wrapper script which calls gcc -std=c99.

c89 is the same concept from an earlier POSIX version.

For some reason, good old "cc" is not required to exist, even though the
specification for c99 is basically "have options like a traditional unix cc"

 

[FredK]

Your suggesting an improvement for a technique that almost certainly
shouldn't be used in the first place.

The unfortunate truth is that I have indeed been in situations where there
were indeed few good choices, including spinning on the HW clock. However,
all I did was note that any reasonable level of optimization would turn this
into (at best) i = 1000000;

 

[Nick]

The unfortunate truth is that I have indeed been in situations where there
were indeed few good choices, including spinning on the HW clock. However,
all I did was note that any reasonable level of optimization would turn this
into (at best) i = 1000000;

Yes, but to give you space to write this you snipped the bit from the
quoted FAQ that had already said that!

 

[Joachim Schmitz]

It sounds like Linuxy stuff, but "OSS environment or linux" is
confusing,

OSS here means "Open Software Services", the POSIX personality of HP NonStop
Kernel (formerly Tandem)

and the Linux systems I use have not usually considered anything
called "c89" to be the "native compiler".

It is called that way on OSS, as opposed to the non-native compiler for the
older home made CISC architecture Tandem used in the old days, but still
available on the newer MIPS and and to some extent on the latest Itanium
architecures.

If you're looking for something that works
on user-mode code on a Unix system, try comp.unix.programmer.

Or, in fact, in comp.sys.tandem (which he did)

bye, Jojo

 

[Nobody]

There isn't any portable way to do this in standard C. However, I believe
that POSIX defines usleep(), which takes a time in microseconds.

POSIX /used/ to define usleep(). It was declared obsolete in POSIX.1-2001
in favour of nanosleep(). It was removed in POSIX.1-2008.