Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: Multitasking at home is great!! (Was Reality check: ....) Keywords: Multitasking Message-ID: <1990Dec23.120454.8724@zorch.SF-Bay.ORG> Date: 23 Dec 90 12:04:54 GMT References: <1990Dec13.155848.8152@maytag.waterloo.edu> <1990Dec22.082240.2443@news.iastate.edu> <26060@uflorida.cis.ufl.EDU> Organization: SF-Bay Public-Access Unix Lines: 108 cr1@beach.cis.ufl.edu () writes: > I've heard Amiga's multitasking defined in so many ways it makes my > head spin. Now, I have a general idea of how things work, but could > someone with a good grasp on the topic please explain to me exactly > how Amiga's multitasking works, and why it can be given the honored > term 'true multitasking' ? Probably the best way to see why the Amiga's is "true multitasking" is by looking at some of the "near multitasking" methods for contrast. I'll assume you understand monotasking: one and only one job in the machine at a time. The next step up the the IBM TSR; a little program that can sit in a little piece of memory, and is brought up by an interrupt, usually a special keystroke combination. Here, you characterize the TSR task: it is _small_ because the main task has to fit in the limited memory; it is normally _idle_, because the OS doesn't know how to swap tasks, the TSR installs a task swapping routine off the interrupt vector to save the main program's registers and load its own; it is _user_ _initiated_; the OS doesn't kick it off for you, you have to do it yourself. In contrast, the Amiga, with a larger flat address space, can have _large_ programs in memory together; they can all be running in an alternation fast enough to look simultaneous, because the OS knows how to swap tasks, and the swapping is _OS_ _initiated_, either because a task says it is going to sleep to wait for an event, or because the OS decides the current process has eaten enough time and it is another process's turn. Above TSRs is the Finder style simultaneously resident processes; the large, flat address space allows several tasks to reside in memory simultaneously, and the OS knows how to swap tasks, but the task swapping is still _user_ _initiated_; the OS sees a click in a new window, and idles the running task associated with another window, and restarts the process associated with the just-clicked window. This is only a little help; it saves the overhead of reloading and finding your place in the routine, but still all the idle time while your finger reaches for the next key is going to waste. In contrast, the Amiga OS takes the initiative to share time among all the running processes; so that you can watch something being drawn or processed in another window, or have it going on in a window out of your sight, while you type or draw or whatever in a separate window. A third sort of "near multitasking" is _cooperative_ multitasking; each software writer is tasked with finding explicit places in the code where control can safely be let go, and put in explicit "wait" commands. This is tough; if the programmer gives up control too often, the overhead eats performance alive, while if the programmer gives up control too infrequently, other processes starve. This has a habit of not working very well, but if the OS doesn't know how to seize control safely, this is the best that can be done. Here, the OS knows how to save and restore registers for various processes, and schedule the next runnable process to run, but the user program is explicitly asking for this service. In contrast, the Amiga OS sets a timer interrupt when it gives control to a new process, and if the process hasn't given back control because it has run out of things to do (e.g., it has finished processing the last keypress, and my finger hasn't hit the next key; these timeslices are _small_), then the timer wakes up the OS which looks around for another process ready to run. If it finds one, then it squirrels away the (already saved by the interrupt) register and other restart information for the (nominally) running process and preempts it to give the next one it's time slice in turn. This is what makes the Amiga a "true preemptive multitasking" system. But there's more, because the Amiga OS also knows another neat trick; it knows how to _prioritize_ tasks. First an example: when I download files, if I run several other tasks, it can happen that I spend enough time away from servicing the serial port that characters repeatedly get lost and the kermit session times out. However, I can use the "changetaskpri" function to give my terminal session a bigger than average slice of the time, and "Big Hog's first place at the trough" when time is available. This works as follows: when the high priority task gives up control, it does it by waiting on some event (character received, buffer full, disk block written, disk block read, etc.). Events, when they occur, wake up the OS and pause the running process through the interrupt mechanism. Now normally, the next task in line, or the current task if its time slice were not yet exhausted, would be scheduled to run next, and the task which is awaiting the event would be moved from the "waiting event" list to the "ready to run" list. With priorities, though, the OS, when an event occurs, after it has marked the associated process "ready to run", looks for the highest priority task in the "ready to run" queue, and gives it the next spot in the run schedule. This way, the kermit task gets run whenever it is ready, the other tasks share the remaining time. The trick is to give the high priorities to the tasks that run out of work often and are willing to ask to be put to sleep (usually, i/o bound processes), while the tasks that just eat cpu cycles (processing bound tasks) get the low priorities. Now there are some complexities here, because you can starve a process if a high priority process eats more cpu cycles than expected, so there is a job of tuning an OS so that even the low priority tasks get at least a little time to run. That's probably more than you wanted to read, and more generic to "true multitasking on any machine", than specific to the Amiga flavor, but perhaps it clarified a few of the issues for you. My apologies in advance for any error in the details; I'm not a world class AmigaOS expert, just the best one inside these four walls. Kent, the man from xanth.