
> >> It's great as long as you never block, but it sucks for making things
> >> wait, because the wait interval will be some multiple of 10 msec rather
> >> than just the time till the lock comes free.
> 
> > On the AIX platform usleep (3) is able to really sleep microseconds without 
> > busying the cpu when called for more than approx. 100 us (the longer the interval,
> > the less busy the cpu gets) .
> > Would this not be ideal for spin_lock, or is usleep not very common ?
> > Linux sais it is in the BSD 4.3 standard.
> 
> HPUX has usleep, but the man page says
> 
>      The usleep() function is included for its historical usage. The
>      setitimer() function is preferred over this function.

I doubt that setitimer has microsecond precision on HPUX.

> In any case, I would expect that all these functions offer accuracy
> no better than the scheduler's regular clock cycle (~ 100Hz) on most
> kernels.

Not on AIX, and I don't beleive that for the majority of other UNIX platforms eighter. 
I do however suspect, that some implementations need a busy loop, which would, 
if at all, only be acceptable on an SMP system.

Andreas

Mon, 19 Mar 2001 13:15:52 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC	 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
>> HPUX has usleep, but the man page says
>> 
>> The usleep() function is included for its historical usage. The
>> setitimer() function is preferred over this function.

> I doubt that setitimer has microsecond precision on HPUX.

Well, if you insist on beating this into the ground:

$ cat timetest.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char** argv)
{
        int i;
        int delay;

        delay = atoi(argv[1]);

        for (i = 0; i < 1000; i++)
                usleep(delay);

        return 0;
}
$ gcc -O -Wall timetest.c
$ time ./a.out 1

real    0m20.02s
user    0m0.04s
sys     0m0.09s
$ time ./a.out 1000

real    0m20.04s
user    0m0.04s
sys     0m0.09s
$ time ./a.out 10000

real    0m20.01s
user    0m0.03s
sys     0m0.08s
$ time ./a.out 20000

real    0m30.03s
user    0m0.04s
sys     0m0.09s
$
$ cat timetest2.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <time.h>
#include <unistd.h>

typedef void (*pqsigfunc) (int);

pqsigfunc
pqsignal(int signo, pqsigfunc func)
{
	struct sigaction act,
				oact;

	act.sa_handler = func;
	sigemptyset(&act.sa_mask);
	act.sa_flags = 0;
	if (signo != SIGALRM)
		act.sa_flags |= SA_RESTART;
	if (sigaction(signo, &act, &oact) < 0)
		return SIG_ERR;
	return oact.sa_handler;
}

void
catch_alarm(int sig)
{
}

int main(int argc, char** argv)
{
	int i;
	struct itimerval iv;
	int delay;

	delay = atoi(argv[1]);

	pqsignal(SIGALRM, catch_alarm);

	for (i = 0; i < 1000; i++)
	{
		iv.it_value.tv_sec = 0;
		iv.it_value.tv_usec = delay;
		iv.it_interval.tv_sec = 0;
		iv.it_interval.tv_usec = 0;
		setitimer(ITIMER_REAL, &iv, NULL);
		pause();
	}

	return 0;
}
$ gcc -O -Wall timetest2.c
$ time ./a.out 1

real    0m20.04s
user    0m0.01s
sys     0m0.05s
$ time ./a.out 1000

real    0m20.02s
user    0m0.01s
sys     0m0.06s
$ time ./a.out 10000

real    0m20.01s
user    0m0.01s
sys     0m0.05s
$ time ./a.out 20000

real    0m30.01s
user    0m0.01s
sys     0m0.06s
$

The usleep man page implies that usleep is actually implemented as a
setitimer call, which would explain the interchangeable results.  In
any case, neither one is useful for timing sub-clock-tick intervals;
in fact they're worse than select().

Anyone else want to try these examples on other platforms?

			regards, tom lane

Mon, 19 Mar 2001 12:27:50 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC 