On Mon, Feb 18, 2008 at 01:26:41PM -0500, Geoff Steckel wrote:
> This is my last posting on this, take heart.
>
> The "threads" advocates have never specified any
> advantages of a program written using that model
> (multiple execution points in a single image)
> over a multiple process model, assuming that
> parallelism is useful.
>
> If the purported advantage is access to shared
> data structures without explicit access mechanisms,
> let's say I strongly disagree that that is an advantage.
> It is a whole set of fatal bugs waiting to happen.
>
> Please enlighten me if there are any -other-
> qualities of this model which are supposed to be
> advantageous to the people paying for and using
> the programs. I count faster development as an
> advantage, increased maintenance (bugs) as a
> disadvantage. The second strongly outweighs the
> first.
I'm neither a thread advocate or opponent.
I thought that the advantage of threads over separate processes was
reduced CPU overhead of context switching.
I see people latching onto the "thread" buzword because the see two
things:
CPUs containing multiple cores, yet the kernel only runs in one
process so if a box has to do mostly kernel stuff, how to take
advantage of those idle cores?
The speed increase of individual CPU cores over time is
gradually decreasing.
Personally, I don't care. I like OpenBSD and I use it on old sinlge-CPU
hardware. If I need more bang, I add a second node and split things up.
I don't need that to happen automatically.
I suppose if I had a 16-core quad-socket Opteron board and needed to make
the box into one giant firewall with 10 Gbit NICs, I'd be disappointed
that the kernel only ran on one of the cores. Then again, if I had that
hardware and that requirement, I'd have the money to offer an OBSD dev
a guaranteed income for the duration. :)
Until then, OpenBSD does what I need on the boxes on which I run it. I
very much appreciate all the work that the devs do.
When I have a __real__ problem, I'll ask straight out.
Thanks all.
Doug.
