From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Assuming that TAS() will succeed the first time is verboten |
Date: | 2000-12-29 04:45:21 |
Message-ID: | 9717.978065121@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ncm(at)zembu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alfred Perlstein | 2000-12-29 04:58:04 | Re: Assuming that TAS() will succeed the first time is verboten |
Previous Message | Tom Lane | 2000-12-29 04:08:05 | Re: Alpha tas() patch |