| From: | ncm(at)zembu(dot)com (Nathan Myers) |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Assuming that TAS() will succeed the first time is verboten |
| Date: | 2000-12-29 20:02:19 |
| Message-ID: | 20001229120219.Q10336@store.zembu.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 29, 2000 at 10:54:00AM -0800, Mikheev, Vadim wrote:
> > > 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.
This is not surprising. Five microseconds is a long time, and the
current s_spincycle does it repeatedly.
> Actually, one slocks are held
> longer than anothers - probably we should use different delays...
I don't understand the last remark. Are you proposing to mix some
random numbers into the delays?
Did you try it with
#define S_NSPINCYCLE 2
int s_spincycle[S_NSPINCYCLE] = {1, 1000};
or even
#define S_NSPINCYCLE 1
int s_spincycle[S_NSPINCYCLE] = {1};
?
Nathan Myers
ncm(at)zembu(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mikheev, Vadim | 2000-12-29 20:20:27 | RE: Assuming that TAS() will succeed the first time is verboten |
| Previous Message | sergiop | 2000-12-29 19:58:02 | Notify with Rules bugs? |