Re: [HACKERS] spin locks
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] spin locks |
Дата | |
Msg-id | Pine.BSF.3.96.980215020849.261H-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | spin locks (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] spin locks
|
Список | 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 по дате отправления: