> 
> On Sun, 15 Feb 1998, Bruce Momjian wrote:
> 
> > > 	I'm not quite sure I follow this...in a multi-cpu environment,
> > > would process_yield() introduce a problem? *raised eyebrow*
> > 
> > Probably.  I would leave the code as-is for multi-cpu systems.
> 
> 	So...how would we determine which is which? *raised eyebrow*
> 
> > Yep, but we need to check for multiple cpu's first before enabling it. 
> > That would be a good trick from configure.
> 
> 	I'm curious, still, as to whether this function would help
> performance on a multi-cpu environment as well...what if 2 processes are
> running on one of two CPUs, and another 2 on the other? *raised eyebrow*

Good point.  You would almost need to know if the one holding the lock
was currently running.  But it wouldn't be un-runnable while it was
holding the spinlock, so it should be run-able, even if it is not
currently running.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Mon, 16 Mar 1998 00:08:03 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] spin locks
> > On Sun, 15 Feb 1998, Bruce Momjian wrote:
> > 
> > > > 	I'm not quite sure I follow this...in a multi-cpu environment,
> > > > would process_yield() introduce a problem? *raised eyebrow*
> > > 
> > > Probably.  I would leave the code as-is for multi-cpu systems.

My experience with exactly this suggests that it doesn't.

> > 	So...how would we determine which is which? *raised eyebrow*
> > 
> > > Yep, but we need to check for multiple cpu's first before enabling it. 
> > > That would be a good trick from configure.
> > 
> > 	I'm curious, still, as to whether this function would help
> > performance on a multi-cpu environment as well...what if 2 processes are
> > running on one of two CPUs, and another 2 on the other? *raised eyebrow*

Unless you have more CPU's than proccesses, having the spinlocks back off
is a win. Since there are not too many lightly loaded 64 cpu machines out
there, for all pratical cases it is a win.
 
> Good point.  You would almost need to know if the one holding the lock
> was currently running.  But it wouldn't be un-runnable while it was
> holding the spinlock, so it should be run-able, even if it is not
> currently running.

But, it can't run until everyone else has run out their timeslice pounding
on the spinlock. Even worse, the effect is to convoy all the backends together
so it becomes even more likely that a spinlock will be contended in the future.

The cpu_yield() or (more portably) select() style of backoff works pretty well.

> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - I realize now that irony has no place in business communications.


Mon, 16 Mar 1998 15:38:10 -0800 (PST)
dg@illustra.com (David Gould)
Re: [HACKERS] spin locks