Re: Assuming that TAS() will succeed the first time is verboten
От | Bruce Momjian |
---|---|
Тема | Re: Assuming that TAS() will succeed the first time is verboten |
Дата | |
Msg-id | 200101020759.CAA15836@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Assuming that TAS() will succeed the first time is verboten (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
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. Another issue is that sched_yield brings in the pthreads library/hooks on some OS's, which we certainly want to avoid. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: