Subject: Re: Mac/Windows question.. Wed May 06 17:06:45 1998 > >I can have eudora checking mail in the background while I'm using > >Netscape or BBEdit or PhotoShop .... Isn't that multitasking? > > Sort of. It's Apple's 'cooperative' multitasking, a form of > multitasking (albeit a less elegant one). For a good > demonstration of it's weakness, click and hold on a menu item > the next time you're making your Mac work (such as downloading a > file, etc.). Watch the whole thing come to a grinding halt until > you release your mouse button. looks like an invitation to geek out if i ever saw one.. ;-) (BTW - Frank: if you really want to glaze your trainees' eyes, give them this as part of the OSI level-1 protocols. it doesn't relate to networking per se, but it does give you some idea of how various operating systems manage programs) first of all, there's a whole group a vaguely similar terms which start with 'multi-' and it would probably be a good idea to cover them to keep things from getting confusing. multitasking : the computer can run more than one program at the same time. multiprocessing : the computer can run programs on more than one CPU. multiprogramming : the computer can run more than one instance of the same program. multiuser : the computer can keep various program instances (and files) separated from each other. a multiuser operating system is almost automatically a multiprogramming one as well, but you /can/ have single-user multiprogramming systems. the Mac OS is a single-user, multitasking, multiprocessing operating system, and i'm pretty sure NT is as well. there are several different solutions for each type of feature, the coolest being, of course, the ones which are the most powerful and flexible. when it comes to multitasking, the central action is what's called 'context switching'. a program's 'context' is a combination of the RAM allocated for that particular program, and the current value of all the variables the OS uses internally. when an OS switches context, it basically takes a snapshot of one program's context, stores it off to one side, then loads the snapshot of another program's context into memory. this is done by a piece of code in the OS that sits explicitly outside of any program's context, called the 'process scheduler'. (BTW - a 'program' is the set of instructions that tell a computer what to do, and a 'process' is a program that's been loaded into memory and given a context. technically, the word 'process' would have been more correct than 'program' in the last paragraph. unfortunately, the term is overloaded because of the little blob of silicon that jiggles electrons being called the 'processor') the most bulletproof way to handle context switching is to have the process scheduler switch programs in and out of context without telling them about it. since the context switching is invisible to the programs, there's no way they can take over the machine. it's sometimes known as 'true multitasking', but the standard name is 'preemptive multitasking'. the traditional preemptive multitasking tactic is to give each program a specific amount of time to run before it gets switched out again. each segment of runtime is referred to as a 'time slice', and the whole thing is called a 'timeslicing' system. this is how unix does multitasking, and the default slice is about 1/100th of a second. a much easier way to handle multitasking is to have all the programs switch their own contexts out periodically. this is what's known as 'cooperative' multitasking. it's a riskier technique than timeslicing, because a program can take over the machine simply by refusing to switch itself out. on the other hand, if all the programs on a machine follow a disciplined switching policy, cooperative multitasking's performance approaches that of timeslicing. now.. the type of multitasking you use also relates to the way your OS passes input to a program, and there are two ways of doing *that*, too. one is called 'event polling' and the other is called 'interrupt trapping'. event polling is (in very broad terms) a lot like the way people handle email. the messages pile up in a box as they arrive, and the user periodically checks to see if anything new is in the box. an event-polling OS catches input signals (keystrokes, mouse clicks, etc.. they're collectively known as 'events') and piles them up in a list called the 'event queue'. in a multitasking, event polling OS, each program has a private event queue as part of its context. the OS identifies signals as they come in and adds them to the appropriate queue. then each program checks its queue for events while its context is switched in. interrupt trapping operates more like a telephone. when it rings, you stop what you're doing and talk to the person who called you. after they hang up, you try to remember what you were doing before you were interrupted. translating that to OS terms, the computer's hardware triggers an electrical signal much like the ring of a telephone (called an interrupt) every time a key is pressed or the mouse is moved. that signal tells the OS to stop running whatever program is currently in memory and hand control to the process scheduler. the scheduler decides which program the event belongs to, then decides A> if the program the event is more important than the one currently switched in, and B> if the specific event is important enough to that program that it would be necessary to force a context switch. to do that, the process scheduler uses a private data structure called the 'priority queue', which shows how important all the programs currently in operation are in relation to each other. the item at the top of the priority queue will be the one that gets switched in during the next time slice. the process scheduler handles all the voodoo necessary to make sure really important stuff (like needing to read data from swap space into RAM) always gets handled before low-priority stuff (like streaming someone's email to the printer), but also makes sure nobody's program is completely submerged and never gets a timeslice. the Mac OS was originally designed as a single-user, single-tasking, event polling OS. when Apple added multitasking in System 7, there were no constraints prompting them to change either the number of users or the way it handled input. therefore, they chose to do cooperative multitasking. to make sure the context switching would be done in a disciplined manner, they grafted it onto the event polling code. the heart of a standard Mac program is a piece of code called the 'event loop', where it polls the OS for the next event, then handles whatever input it finds. to make the looping more efficient, the program agrees to wait a certain amount of time (measured in 'ticks', each of which is 1/60th of a second) for the next event. under the Apple cooperative multitasking system, the OS switches the program out as soon as it requests the next event. it then cycles through all the other programs waiting in the background until the time limit has passed, then switches the foreground program's context back in, and passes it whatever events may have arrived while it was waiting. it's possible to write programs which simply take over a Mac, but since they've worked so hard indoctrinating developers to follow the Apple Human Interface Guidelines, it doesn't happen often, and certainly not in mainstream commercial software. i don't know enough about NT's internals to say how it handles multitasking, but i'm pretty sure DOS was dsigned as an interrupt-trapping, single-user, single-tasking OS. basically, it gave the program complete control over the hardware, then defined a set of interrupt routines which got triggered whenever a key was pressed. that would tie in logically with the IRQ settings it uses for devices, assigning each piece of hardware a specific interrupt channel. the device driver would be assigned to the appropriate IRQ number, and would be triggered every time a signal comes in from that device. as i understand it, and i won't put much strength behind this, because it's purely conjecture based on tidbits i've heard from Windows techs, Win95 uses a simplified form of timeslicing. it's still a single-user system, so the OS can just cycle through the background processes without having to worry about a priority queue. i know NT is derived from VMS, which was a popular multiuser mainframe OS back in the '80s, so i assume it uses some sort of true timeslicing, but is still a single-user machine. Rhapsody is based on the NextOS, which was in turn derived loosely from unix (BSD, but i'm not sure which version). as i understand it, Rhapsody is a fully multiprogramming, multiuser, timeslicing OS, like its predecessors.