Brent Verner <brent@rcfile.org> writes:
> Using a single-processor machine, we're not going to get any lower
> sleep times than ~10ms from either usleep or select on linux, and
> usleep is always longer.
Ah, so usleep is just being stricter about rounding up the requested
delay? That would explain the results all right.
> Looks like increasing spins allows
> the process to get the lock before the usleep/select is run
Right. Up to a point, increasing spins improves the odds of acquiring
the lock without having to release the processor.
What I should've thought of is to try sched_yield() as well, which is
the operation we *really* want here, and it is available on this version
of Linux. Off to run another batch of tests ...
regards, tom lane
