From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | dz(at)cs(dot)unitn(dot)it (Massimo Dal Zotto) |
Cc: | hackers(at)postgreSQL(dot)org (PostgreSQL-development) |
Subject: | spin locks |
Date: | 1998-02-15 05:27:17 |
Message-ID: | 199802150527.AAA15181@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)candle(dot)pha(dot)pa(dot)us
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-02-15 06:11:04 | Re: [HACKERS] spin locks |
Previous Message | Brook Milligan | 1998-02-15 05:17:22 | Re: [PORTS] Re: [HACKERS] Valid ports for v6.3 -- NetBSD/i386 compile errors |