Subject: Re: What is happening with libpthread???
To: None <firstname.lastname@example.org>
From: Christian Kuhtz <email@example.com>
Date: 01/21/1997 08:43:23
On Tue, 21 Jan 1997 07:31:58 -0500, firstname.lastname@example.org wrote:
> 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?
They're not really opposites.
Multitasking usually refers to multiple processes on a particular processor.
You can have multiple threads within a process.
This can be on *one* processor or multiple processors. You need a type of
multitasking system to provide the general scheduling mechanisms on which
multitasking operating systems are based on. Sometimes threads can add
additional granularity to that scheduling mechanism.
Things get a little fuzzy when you look at the kernel level, so, take this
with a grain of salt and relate it to what most people using it for: user
Generally, you have some sort of a program counter which points at a
particular part within a process, to indicate where the execution is
Processes generally don't share their image with others, each has its own
Multiple threads within a process share the same memory image of their host
process, and you essentially have a bunch of different program counters within
a process. ;-)
That causes a couple of "problems" which are generally referred to under the
topic synchronization. You need to make sure that while one thread is
modifying a variable, nobody else is messing with it, too, etc etc (locking of
varied degrees of granularity), and if you want to exchange data at certain
points within your threads, you need to make sure that they eventually get to
those points and for instance wait for other threads to get there as well, and
tell each other that they've arrived where they were supposed to.
Because the threads of a particular process share the same memory image
within a process, they don't need to make system calls to synchronize with
other threads (as processes would have to do to synchronize with other
processes); they simply check on the status of a variable, a spot somewhere
within their host's memory image. Much, much more efficient. And there are
other things like it.
Threads libraries, such as POSIX Pthreads, or Mach C-Threads, provide very
slick mechanisms to accomplish all those thread management activities from
within user space. Some are a little different than others, mostly because
they were designed for slightly different things and have different resources
available to them. Pthreads is an attempt to provide the same, standardized
threads environment across platforms, with little respect to what OS it is
running on. Mach C-Threads are usually only available on Mach mk based
machines, because of the relatively unique kernel structure underneath. You
could certainly emulate them to a degree with a Pthreads library, but it
wouldn't be the same, because you don't have the same scheduler etc etc.
Does that make sense? ;-)