Re: Spinlocks, yet again: analysis and proposed patches

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Spinlocks, yet again: analysis and proposed patches
Дата
Msg-id 23028.1126622378@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Spinlocks, yet again: analysis and proposed patches  (Greg Stark <gsstark@mit.edu>)
Ответы Re: Spinlocks, yet again: analysis and proposed patches  (Stephen Frost <sfrost@snowman.net>)
Re: Spinlocks, yet again: analysis and proposed patches  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Marko Kreen <marko@l-t.ee> writes:
> (I speculate that it's set up to only yield the processor to other
> processes already affiliated to that processor.  In any case, it
> is definitely capable of getting through 10000 yields without
> running the guy who's holding the spinlock.)

> Maybe it should try sched_yield once and then use select after that?

I tried that, actually, but it didn't seem to offer any particular
benefit.  (Maybe it would have helped more on older Linux kernels before
they changed sched_yield?)

I'm feeling even more disenchanted with sched_yield now that Marko
pointed out that the behavior was changed recently.  Here we have a
construct that is not portable cross-platform, does not act as
documented in its man page, and the kernel guys feel free to whack its
behavior around in major ways without documenting that either.  It seems
to be a crap-shoot whether it will be useful on any particular machine
or not.  At least with the select() code we can be reasonably confident
we know what will happen.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Spinlocks, yet again: analysis and proposed patches
Следующее
От: Roman Neuhauser
Дата:
Сообщение: bug #1702: nested composite types in plpgsql