Subject: Re: What is happening with libpthread???
To: None <shane@border.com>
From: Christian Kuhtz <kuhtz@ix.netcom.com>
List: current-users
Date: 01/21/1997 08:43:23
On Tue, 21 Jan 1997 07:31:58 -0500, shane@border.com 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
> justified.
>
> 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  
space applications.

Generally, you have some sort of a program counter which points at a  
particular part within a process, to indicate where the execution is  
happening.

Processes generally don't share their image with others, each has its own  
memory image.

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? ;-)

Regards,
Chris