ncm@zembu.com (Nathan Myers) writes:
> On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
>> 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.
There's been some talk of reimplementing S_LOCK() and friends to use
Posix user-space semaphores, on platforms that provide such. But it'll
be a *long* time before we can expect such facilities to be available
everywhere.
> 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.
Yeah, I've wondered whether the 0 entries in s_spincycle[] shouldn't be
1. The code author evidently expected select() to at least yield the
processor even with delay 0, but the select() man pages I have handy
say that it will "return immediately" when delay is 0.
regards, tom lane
