On 26 Sep 2001, Doug McNaught wrote:
> This depends on your system. Solaris has a huge difference between
> thread and process context switch times, whereas Linux has very little
> difference (and in fact a Linux process context switch is about as
> fast as a Solaris thread switch on the same hardware--Solaris is just
> a pig when it comes to process context switching).
Yeah, I kinda commented on this in another e-mail. Linux has some nice
tweaks for software using the forking model, but I am sure a couple of
Solaris admins out there like to run PostgreSQL. ;-) You are right in
that it is very system dependent. I should have prefaced it with "In
general ..."
> > I can't comment on the "isolate data" line. I am still trying to figure
> > that one out.
>
> I think his point is one of clarity and maintainability. When a
> task's data is explicitly shared (via shared memory of some sort) it's
> fairly clear when you're accessing shared data and need to worry about
> locking. Whereas when all data is shared by default (as with threads)
> it's very easy to miss places where threads can step on each other.
Well, I understand what you are saying and you are correct. The situation
is that when you implement anything using pthreads you lock your
variables (which is where the major performance penalty comes into play
with threads). Now, the kicker is how you lock them. Depending on how
you do it (as per discussion earlier on this list concerning threads) it
can be faster or slower. It all depends on what model you use.
Data is not explicitely shared between threads unless you make it so. The
threads just share the same stack and all of that, but you can't
(shouldn't is probably a better word) really access anything you don't have
an address for. Threads just makes it easier to share if you want to.
Also, see my other e-mail to the list concerning TSDs.
--
//========================================================\\
|| D. Hageman <dhageman@dracken.com> ||
\\========================================================//