Re: Spinlock performance improvement proposal

On Wed, 26 Sep 2001, mlw wrote:
>
> I can only think of two objectives for threading. (1) running the various
> connections in their own thread instead of their own process. (2) running
> complex queries across multiple threads.
>
> For item (1) I see no value to this. It is a lot of work with no tangible
> benefit. If you have an old fashion pthreads implementation, it will hurt
> performance because are scheduled within the single process's time slice..

Old fashion ... as in a userland library that implements POSIX threads?
Well, I would agree. However, most *modern* implementations are done in
the kernel or kernel and userland coop model and don't have this
limitation (as you mention later in your e-mail). You have kinda hit on
one of my gripes about computers in general. At what point in time does
one say something is obsolete or too old to support anymore - that it
hinders progress instead of adding a "feature"?

> 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.

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

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.

> For item (2) I can see how that could speed up queries in a low utilization
> system, and that would be cool, but in a server that is under load, threading
> the queries probably be less efficient.

Well, I don't follow your logic and you didn't give any substance to back
up your claim. I am willing to listen.

Another thought ... Oracle uses threads doesn't it or at least it has a
single processor and multi-processor version last time I knew ... which do
they claim is better? (Not saying that Oracle's proclimation of what is
good and what is not matters, but it is good for another view point).

--
//========================================================\\
|| D. Hageman <dhageman(at)dracken(dot)com> ||
\\========================================================//