Re: Spinlock performance improvement proposal

"D. Hageman" <dhageman(at)dracken(dot)com> writes:

> > you have a newer kernel scheduled implementation, then you will have the same
> > scheduling as separate processes. The only thing you will need to do is
> > switch your brain from figuring out how to share data, to trying to figure
> > out how to isolate data. A multithreaded implementation lacks many of the
> > benefits and robustness of a multiprocess implementation.
>
> 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.

When using a kernel threading model, it's not obvious to me that the
kernel will switch between threads much faster than it will switch
between processes. As far as I can see, the only potential savings is
not reloading the pointers to the page tables. That is not nothing,
but it is also not a lot.

> I can't comment on the "isolate data" line. I am still trying to figure
> that one out.

Sometimes you need data which is specific to a particular thread.
Basically, you have to look at every global variable in the Postgres
backend, and determine whether to share it among all threads or to
make it thread-specific. In other words, you have to take extra steps
to isolate the data within the thread. This is the reverse of the
current situation, in which you have to take extra steps to share data
among all backend processes.

> That last line is a troll if I every saw it ;-) I will agree that threads
> isn't for everything and that it has costs just like everything else. Let
> me stress that last part - like everything else. Certain costs exist in
> the present model, nothing is - how should we say ... perfect.

When writing in C, threading inevitably loses robustness. Erratic
behaviour by one thread, perhaps in a user defined function, can
subtly corrupt the entire system, rather than just that thread. Part
of defensive programming is building barriers between different parts
of a system. Process boundaries are a powerful barrier.

(Actually, though, Postgres is already vulnerable to erratic behaviour
because any backend process can corrupt the shared buffer pool.)

Ian