Subject: Re: What is happening with libpthread???
To: None <firstname.lastname@example.org, current-users@NetBSD.ORG>
From: None <email@example.com>
Date: 01/21/1997 07:31:58
I realize that this is a bit of a "newbie" kind of question, but you
posted this note to current-users, rather than to tech-kern, so I feel
What is the difference between multi-tasking and multi-threading?
I don't want to start this thread off again, but here's my rationale for
proposing and doing what I am already doing:
I have done Mach mk ports numerous times, and for my it is a fairly
straightforward business, and I believe I have a thorough enough
understanding of Mach internals to be successful at it and come up with
something which will not only work, but perform well.
The Mach mk provides only the most basic functions. Mach-UX relies on a
OS server to provide an API. Or, in case it is Mach-US we're dealing
with, emulation libraries to possibly provide multiple APIs on a per
However, there are a bunch of goodies that come in the clue bag with
this, and two of them I particularly like: 1.) kernel multithreading and
It is a fully threaded kernel, and a rock-solid, fast kernel thread API
is available to the user, which can be easily adapted to other threading
API's if so desired, such as POSIX3.1c threads (Pthreads).
Further, I believe, that the fact that Mach mk's are by design meant to
be multiprocessing kernels, makes it very easy to support multiprocessor
environments. To me, it makes more sense to take building blocks meant
to support a particular function, than coax something that isn't meant to
provide multiprocessing to provide multiprocessing.
And since Mach mk's 3.0 and up, even non-shared memory multiprocessor
environments are possible and easily implemented. The APIs themselves
have no clue what it is below their ports to the mk (99.9% of the time).
The whole OS design is much more modular, which makes porting easier as
well. NetBSD has done a tremendous amount of porting work, which is
IMHO, NetBSD is a very fine uniprocessor OS. Efficiency for a different
environment might need a different approach than driving a uniprocessor
OS to be a multiprocessor OS. Especially since there are no threads in
the current kernel, IMHO, this job can never been of great efficiency.
It'll work, no doubt, but it won't be the best we can do.
Because the NetBSD server's API will be a superset of the current NetBSD
API, current apps will continue to run at the very least after
With a little extra effort, even binary compatibility can be provided.
The argument that Mach mk has more overhead than traditional
architectures is not true per se. Multithreading provides for
significant advantages even on uniprocessor architectures when high I/O
demands are to be serviced. For efficient multiprocessing, threading is
a requirement, not an option. And predominantly userland threading
implementations just don't cut it(TM).
That's my story. Comments welcome, flames >/dev/null.
We'll see what happens.
Christian Kuhtz <firstname.lastname@example.org>