Re: Spinlock performance improvement proposal

Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> > >
> > > > Save for the fact that the kernel can switch between threads faster then
> > > > it can switch processes considering threads share the same address space,
> > > > stack, code, etc. If need be sharing the data between threads is much
> > > > easier then sharing between processes.
> > >
> > > Just a clarification but because we fork each backend, don't they share
> > > the same code space? Data/stack is still separate.
> >
> > In Linux and many modern UNIX programs, you share everything at fork time. The
> > data and stack pages are marked "copy on write" which means that if you touch
> > it, the processor traps and drops into the memory manager code. A new page is
> > created and replaced into your address space where the page, to which you were
> > going to write, was.
>
> Yes, very true. My point was that backends already share code space and
> non-modified data space. It is just modified data and stack that is
> non-shared, but then again, they would have to be non-shared in a
> threaded backend too.

In a threaded system everything would be shared, depending on the OS, even the
stacks. The stacks could be allocated out of the same global pool.

You would need something like thread local storage to deal with isolating
aviables from one thread to another. That always seemed more trouble that it
was worth. Either that or go through each and every global variable in
PostgreSQL and make it a member of a structure, and create an instance of this
structure for each new thread.

IMHO once you go down the road of using Thread local memory, you are getting to
the same level of difficulty (for the OS) in task switching as just switching
processes. The exception to this is Windows where tasks are such a big hit.

I think threaded software is quite usefull, and I have a number of thread based
servers in production. However, my experience tells me that the work trying to
move PostgreSQL to a threaded ebvironment would be extensive and have little or
no tangable benefit.

I would rather see stuff like 64bit OIDs, three options for function definition
(short cache, nocache, long cache), etc. than to waste time making PostgreSQL
threaded. That's just my opinion.