Re: [HACKERS] spin locks

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it>, PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] spin locks
Date: 1998-02-15 06:11:04
Message-ID: Pine.BSF.3.96.980215020849.261H-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org

In response to

  • spin locks at 1998-02-15 05:27:17 from Bruce Momjian

Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Mergl 1998-02-15 06:46:35 Re: [HACKERS] wishlist: PQfsize
Previous Message Bruce Momjian 1998-02-15 05:27:17 spin locks