Re: Assuming that TAS() will succeed the first time is verboten

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

In response to

Browse pgsql-hackers by date

  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