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

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assuming that TAS() will succeed the first time is verboten
Date: 2000-12-29 04:58:04
Message-ID: 20001228205803.M19572@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001228 14:25] wrote:
> ncm(at)zembu(dot)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.
> 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.

It sounds pretty bad, if you have a contested lock you'll trap into
the kernel each time you miss, crossing the protection boundry and
then waiting. It's a tough call to make, because on UP systems
you loose bigtime by spinning for your quantum, however on SMP
systems there's a chance that the lock is owned by a process on
another CPU and spinning might be benificial.

One trick that may help is calling sched_yield(2) on a lock miss,
it's a POSIX call and quite new so you'd need a 'configure' test
for it.

http://www.freebsd.org/cgi/man.cgi?query=sched_yield&apropos=0&sektion=0&manpath=FreeBSD+4.2-RELEASE&format=html

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2000-12-29 04:58:13 Re: Alpha tas() patch
Previous Message Tom Lane 2000-12-29 04:45:21 Re: Assuming that TAS() will succeed the first time is verboten