Re[2]: [Am-info] O/S 2 support - slightly off topic (my apologies)

[Erick Andrews]

On 16 Mar 2002 15:13:00 -0600, Eric M. Hopper wrote:

>On Sat, 2002-03-16 at 14:12, Mitch Stone wrote:
>> Allow me to ask a simple-minded technical question: what if anything is 
>> the relationship between multithreading and preemptive multitasking?
>
>Multithreading and preemptive scheduling are, in one sense, strongly
>related, and in another, orthogonal concepts.  Most people do not think
>of cooperative multithreading as multithreading at all.  So, in most
>people's minds, multithreading is something that only happens when you
>have preemptive scheduling.
>
>> The main reason I ask, is because for years we heard that the MacOS was 
>> technically inferior to Windows because it used a less sophisticated 
>> scheme for multitasking (cooperative). This method gave explicit CPU 
>> priority to the front-most active application. What I've found since 
>> moving to the threaded OS X, is that the performance of some power-hungry 
>> apps suffers because these priorities can no longer be set (as readily) by 
>> the user.
>
>Actually, here's a good explanation of the terms preemptive,
>cooperative, multitasking, and multithreading in the context of managing
>CPU resources...
>
>Multitasking vs. multithreading refers to two different ways to divide
>things up.  I liken multitasking to having a lot desks (think of the
>inside of your computer as a frantic bookkeeping bureaucracy) on them
>and specific in and out boxes.  I liken multithreading to having one
>desk with lots of people using it simultaneously and having all of them
>have some kind of agreement about which one gets to work on which pieces
>of paper when so there's no confusion.
>
>To extend the desktop metaphor further...
>
>Cooperative scheduling is like a single guy doing a small, complete task
>and then moving on, either to another group of papers on the same desk
>(multithreading) or another desk (multitasking).  Preemptive scheduling
>is like having lots of guys.  If you only have one CPU, all the guys but
>one are halted in time while the one works, but which one is working and
>which one is halted in time changes around semi-randomly (according to
>the OSes scheduling algorithm).  If you have two CPUs, all but two guys
>are halted in time, etc...
>
>Multithreading systems almost invariably (with the exception of some
>specialized embedded systems) also do multitasking.  Not all
>multitasking systems can do multithreading.
>
>Preemptive multithreading is hard and error prone because preemptive
>means you have several actors, and multithreading means a single desk of
>papers.  You end up having to have a complex agreement between all the
>actors about who gets to modify which piece of paper when in order to
>avoid confusion.  That agreement is very difficult to get right.
>
>This is a big issue for me because my big programming project (the
>StreamModule system) is something that allows you to do cooperative
>multithreading.  Later, it will allow (in a very restricted and
>disciplined way) a mix of cooperative and preemptive multithreading.
>
>I hope that helps,

I sort of like your analogy with all the desks, in-boxes, out-boxes, and 
people and/or worker-bees doing tasks.

Yet like any good film project or stage act, you need a good director.

Often, the names we give to these functions can be vague to those
less indoctrinated in OS design.  Perhaps besides scheduling (which
*is* the CPU utilization goal) we might introduce the time-honored 
term of "process", and who's subordinate to whom.

The way I think is that "threads" belong to "processes", and "processes"
are scheduled by the OS, but then I might be over simplifying a bit.

-- 
Erick Andrews