From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Kreen <marko(at)l-t(dot)ee>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Spinlocks, yet again: analysis and proposed patches |
Date: | 2005-09-14 07:30:05 |
Message-ID: | 87d5ncm7ia.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > I'm starting to think that we might have to succumb to having a compile
> > option "optimize for multiprocessor" or "optimize for single processor".
> > It's pretty hard to see how we'd alter a data structure decision like
> > this on the fly.
>
> I'd really hate to see this happen.
I suspect you're thinking too hard about this. It's not like some LWLocks
would need SMP spinlocks and others uniprocessor locks. And it's not like it's
going to change dynamically.
Wouldn't it just be a couple:
if (multiprocessor) {
complex version
} else {
simple version
}
Ugly to be sure but it's not going to spread to other areas of the source base
and you know the if statement isn't going to be growing any more arms.
It's no uglier than doing the same thing with an #ifdef anyways.
If you really really want to have two versions and you think using function
pointers would impose too big a performance penalty you could play linker
games. But that way lies madness.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paesold | 2005-09-14 07:41:46 | Re: Spinlocks, yet again: analysis and proposed patches |
Previous Message | Dave Page | 2005-09-14 07:18:14 | Re: Spinlocks, yet again: analysis and proposed patches |