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

  What is the difference between multi-tasking and multi-threading?

  Thanks

  sakm


  khutz writes:


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

  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
  2.) multiprocessing.

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

  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
   recompilation.
  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 <ckuhtz@paranet.com>