Re: Assuming that TAS() will succeed the first time is verboten
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Assuming that TAS() will succeed the first time is verboten |
| Дата | |
| Msg-id | 9850.978067943@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Assuming that TAS() will succeed the first time is verboten (Alfred Perlstein <bright@wintelcom.net>) |
| Ответы |
Re: Assuming that TAS() will succeed the first time is verboten
|
| Список | pgsql-hackers |
Alfred Perlstein <bright@wintelcom.net> writes:
> One trick that may help is calling sched_yield(2) on a lock miss,
> it's a POSIX call and quite new so you'd need a 'configure' test
> for it.
The author of the current s_lock code seems to have thought that
select() with a zero delay would do the equivalent of sched_yield().
I'm not sure if that's true on very many kernels, if indeed any...
I doubt we could buy much by depending on sched_yield(); if you want
to assume POSIX facilities, ISTM you might as well go for user-space
semaphores and forget the whole TAS mechanism.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера