Re: Spinning verses sleeping in s_lock

mlw <markw(at)mohawksoft(dot)com> writes:
> (1) Why doesn't Postgresql use sched_yield() instead of select() in s_lock()?

Portability concerns. It is something that I think we ought to look at
in a future release. However, based on my latest comparisons I'm no
longer willing to think of it as a "must fix" for 7.2.

> (2) TAS fails when it should work on the alpha? Is it known why?

Because the Alpha guys designed it to fail anytime it couldn't succeed
immediately, or something like that. Consult the archives around end of
Dec 2000. One thing I recall is that the first TAS attempt after a
process gains the CPU is almost guaranteed to fail, because the
necessary page lookup table entries haven't been faulted in. The first
version of WAL support in beta 7.1 assumed it could TAS once and yield
the CPU on failure, and guess what: it spun forever on Alphas.

> SMP has a lot of issues that are not completely obvious. I really don't like
> spinlocks in userland. In an active server, wasting CPU cycles is just wrong.

If it takes more cycles to yield the CPU (and dispatch another process,
and eventually redispatch your own process) than it does to spin until
the other guy lets go of the lock, then "wasting" CPU cycles by spinning
is not wrong. In our present usage of spinlocks this condition is
almost guaranteed to be true, for a multiprocessor system. There are
no OSes that can do two process dispatches in ~20 instructions.

The real issue here is to devise a solution that costs less than 20
instructions on average in the multiprocessor case, while not wasting
cycles in the uniprocessor case. And is portable. That's a tough
challenge. I think we will want to look at developing code to determine
whether there's more than one CPU, for sure; one algorithm to do both
cases optimally seems impossible.

regards, tom lane