Skip site navigation (1) Skip section navigation (2)

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

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assuming that TAS() will succeed the first time is verboten
Date: 2000-12-28 23:17:51
Message-ID: 20001228151751.O10336@store.zembu.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane 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.

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(at)zembu(dot)com

In response to

Responses

pgsql-hackers by date

Next:From: Dominic J. EidsonDate: 2000-12-28 23:26:23
Subject: Re: Assuming that TAS() will succeed the first time is verboten
Previous:From: Tom LaneDate: 2000-12-28 22:12:22
Subject: Re: Assuming that TAS() will succeed the first time is verboten

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group