On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
> ncm@zembu.com (Nathan Myers) writes:
> > I wonder about the advisability of using spinlocks in user-level code
> > which might be swapped out any time.
>
> The reason we use spinlocks is that we expect the lock to succeed (not
> block) the majority of the time, and we want the code to fall through
> as quickly as possible in that case. In particular we do *not* want to
> expend a kernel call when we are able to acquire the lock immediately.
Most implementations of mutex and semaphore do no system call if they
get the lock; if they fail to get the lock, they block in the kernel
without any need for complicated "back-off" loops.
> It's not a true "spin" lock because we don't sit in a tight loop when
> we do have to wait for the lock --- we use select() to delay for a small
> interval before trying again. See src/backend/storage/buffer/s_lock.c.
>
> The design is reasonable, even if a little bit offbeat.
I suspect "a little bit offbeat" qualifies as an extreme understatement.
In particular, it's not really a spinlock, in the standard sense.
The code is based on some odd assumptions. A select() with 0 delay
returns immediately unless there is an interrupt during its (very short!)
time in kernel space. On a single processor this is extremely unlikely
to result in a change to the lock. I suspect
#define S_NSPINCYCLE 2 #define S_MAX_BUSY 1000 * S_NSPINCYCLE
int s_spincycle[S_NSPINCYCLE] = {1,10000};
would give better results, assuming we want to keep the existing
mechanism.
Nathan Myers
ncm@zembu.com