Re: Spinlocks, yet again: analysis and proposed patches - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Spinlocks, yet again: analysis and proposed patches
Date
Msg-id 87d5ncm7ia.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Spinlocks, yet again: analysis and proposed patches  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:

> * Tom Lane (tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Next
From: "Michael Paesold"
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches