Re: [HACKERS] spin locks - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] spin locks
Date
Msg-id Pine.BSF.3.96.980215020849.261H-100000@thelab.hub.org
Whole thread Raw
In response to spin locks  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] spin locks  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: spin locks
Next
From: "Kenji T. Hollis"
Date:
Subject: Re: [HACKERS] PostGreSQL v6.2.1 for Linux Alpha