Thread: spin locks

spin locks

From
Bruce Momjian
Date:
> spin-lock.patch
>
>     I'm not sure if this is really useful, but it seems stupid to have
>     a backend wasting cpu cycles in a busy loop while the process which
>     should release the lock is waiting for the cpu. So I added a call
>     to process_yield() if the spin lock can't obtained.
>     This has been implemented and tested only on Linux. I don't know if
>     other OS have process_yield(). If someone can check please do it.

Massimo brings up a good point.  Most of our s_lock.h locking does asm
mutex loops looking for a lock.  Unless we are using a multi-cpu
machine, there is no way this is going to change while we are spinning.

Linux has process_yield(), but most OS's don't.  Is there a
platform-independent way to relinquish the cpu if the first attempt at
the spinlock fails?  Would a select() of 1 microsecond work?

--
Bruce Momjian
maillist@candle.pha.pa.us

Re: [HACKERS] spin locks

From
The Hermit Hacker
Date:
On Sun, 15 Feb 1998, Bruce Momjian wrote:

> > spin-lock.patch
> >
> >     I'm not sure if this is really useful, but it seems stupid to have
> >     a backend wasting cpu cycles in a busy loop while the process which
> >     should release the lock is waiting for the cpu. So I added a call
> >     to process_yield() if the spin lock can't obtained.
> >     This has been implemented and tested only on Linux. I don't know if
> >     other OS have process_yield(). If someone can check please do it.
>
> Massimo brings up a good point.  Most of our s_lock.h locking does asm
> mutex loops looking for a lock.  Unless we are using a multi-cpu
> machine, there is no way this is going to change while we are spinning.

    I'm not quite sure I follow this...in a multi-cpu environment,
would process_yield() introduce a problem? *raised eyebrow*

> Linux has process_yield(), but most OS's don't.  Is there a
> platform-independent way to relinquish the cpu if the first attempt at
> the spinlock fails?  Would a select() of 1 microsecond work?

    There is nothing wrong with introducing an OS specific
optimization to the code...we can add a HAVE_PROCESS_YIELD to config.h and
if a system has it, use it...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


Re: [HACKERS] spin locks

From
Bruce Momjian
Date:
>
> On Sun, 15 Feb 1998, Bruce Momjian wrote:
>
> > > spin-lock.patch
> > >
> > >     I'm not sure if this is really useful, but it seems stupid to have
> > >     a backend wasting cpu cycles in a busy loop while the process which
> > >     should release the lock is waiting for the cpu. So I added a call
> > >     to process_yield() if the spin lock can't obtained.
> > >     This has been implemented and tested only on Linux. I don't know if
> > >     other OS have process_yield(). If someone can check please do it.
> >
> > Massimo brings up a good point.  Most of our s_lock.h locking does asm
> > mutex loops looking for a lock.  Unless we are using a multi-cpu
> > machine, there is no way this is going to change while we are spinning.
>
>     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.

>
> > Linux has process_yield(), but most OS's don't.  Is there a
> > platform-independent way to relinquish the cpu if the first attempt at
> > the spinlock fails?  Would a select() of 1 microsecond work?
>
>     There is nothing wrong with introducing an OS specific
> optimization to the code...we can add a HAVE_PROCESS_YIELD to config.h and
> if a system has it, use it...

Yep, but we need to check for multiple cpu's first before enabling it.
That would be a good trick from configure.

--
Bruce Momjian
maillist@candle.pha.pa.us

Re: [HACKERS] spin locks

From
The Hermit Hacker
Date:
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*

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


Re: [HACKERS] spin locks

From
Jordan Henderson
Date:
Folks,

On the spin lock and multiple CPU's, this should not be
a compile time issue, but a runtime issue. What do you
think?

Jordan Henderson


Re: [HACKERS] spin locks

From
The Hermit Hacker
Date:
On Sun, 15 Feb 1998, Jordan Henderson wrote:

> Folks,
>
> On the spin lock and multiple CPU's, this should not be
> a compile time issue, but a runtime issue. What do you
> think?

    And you are proposing...?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


Re: [HACKERS] spin locks

From
Jordan Henderson
Date:
Folks,

On the thread in regards to spinlocks and multiple CPU's.
The line of thought appeared to be select a compile
time option to determine behavior, and whether to yield or not.

I am thinking that if it comes to having alternate code, the
system should be able to make the determination at runtime,
not compile time. I don't know if all of the platforms supported
have a version of the sysinfo utility, but here is how, at runtime
it gets the number of CPUS available:

**** EXCERPTED FROM SYSINFO SOURCE 3.3.1 ****
/*
 * Use sysconf() to find number of CPU's.
 */
extern char *GetNumCpuSysconf()
{
    int                Num = -1;
    static char               *NumStr = NULL;

    if (NumStr)
    return(NumStr);

#if    defined(_SC_NPROCESSORS_CONF)
    Num = (int) sysconf(_SC_NPROCESSORS_CONF);
    if (Num >= 0) {
    NumStr = itoa(Num);
    if (NumStr)
        NumStr = strdup(NumStr);
    }
#endif    /* _SC_NPROCESSORS_CONF */

    return(NumStr);
}

What I would propose, if the decision is made to yield,
that at initialization time, the number of CPU's available
are determined, and a flag set, or, an indirect jump
changed. This would allow the software to have both
personalities, depending on which system it found it
self running on.

Thoughts?
Jordan Henderson


Re: [HACKERS] spin locks

From
Bruce Momjian
Date:
>
> Folks,
>
> On the spin lock and multiple CPU's, this should not be
> a compile time issue, but a runtime issue. What do you
> think?
>
> Jordan Henderson
>
>
>

Yes.

--
Bruce Momjian
maillist@candle.pha.pa.us

Re: [HACKERS] spin locks

From
Massimo Dal Zotto
Date:
>
> >
> > Folks,
> >
> > On the spin lock and multiple CPU's, this should not be
> > a compile time issue, but a runtime issue. What do you
> > think?
> >
> > Jordan Henderson
> >
> >
> >
>
> Yes.

Yes, if we have the tprintf patch we can also add an option flag and change
it un the fly while the backends are running.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto                e-mail:  dz@cs.unitn.it            |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+


Re: [HACKERS] spin locks

From
Bruce Momjian
Date:
>
> 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)

Re: [HACKERS] spin locks

From
dg@illustra.com (David Gould)
Date:
> > 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.