> > The code is based on some odd assumptions. A select() with 0 delay > > returns immediately unless there is an interrupt during its > > (very short!) time in kernel space. > > Yeah, I've wondered whether the 0 entries in s_spincycle[] > shouldn't be 1. The code author evidently expected select() > to at least yield the processor even with delay 0, but the select() > man pages I have handy say that it will "return immediately" when delay > is 0. I've run some tests with 5 instead of 0 and afair performance was worse, so we should carefully test !0 values. Actually, one slocks are held longer than anothers - probably we should use different delays... Vadim
- Re: [HACKERS] Assuming that TAS() will succeed the first... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will succeed the ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succeed ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will succ... Dominic J. Eidson
- Re: [HACKERS] Assuming that TAS() will ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will succ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succeed ... Alfred Perlstein
- Re: [HACKERS] Assuming that TAS() will succ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will ... Bruce Momjian
- Re: [HACKERS] Assuming that TAS() ... Alfred Perlstein
- Re: [HACKERS] Assuming that TAS() will succeed the first... Mikheev, Vadim
- RE: [HACKERS] Assuming that TAS() will succeed the first... Mikheev, Vadim
- Re: [HACKERS] Assuming that TAS() will succeed the ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will succeed ... Bruce Momjian
- Re: [HACKERS] Assuming that TAS() will succ... Nathan Myers
- Re: [HACKERS] Assuming that TAS() will succ... Tom Lane
- Re: [HACKERS] Assuming that TAS() will ... Bruce Momjian