oster@lapis.berkeley.edu (David Phillip Oster) (09/26/86)
In article <255@husc6.HARVARD.EDU> (mitsuharu hadeishi) writes: > >The Mac software architecture, although revolutionary in its time, makes >it MUCH more difficult for old applications to run comfortably in a >multitasking environment (and much less efficient, since an event loop >is inherently less efficient than a event-driven task (that uses >task Wait()ing.)) ... Please correct me when I am wrong, but I'm under the impression that the Amiga has both time-sliced multi-tasking and, a routine called Wait() hat lowers the priority of an application. The application is supposed to call Wait() when it has nothing to do. How do Amiga programmers handle continuous mouse tracking so their programs can change the cursor shape as the cursor enters different kinds of objects? On the Mac, the equivalent routine to Wait() is called SystemTask. SystemTask() suspends its caller and gives other applications a chance to run. If you want time sliced multi-tasking, you just queue a task on the vertical interrupt queue, to be awakened at a future time that is a essentially a parameter of the queue call. Interrupt handlers are also straight forward, and are used in Mac device drivers. My Menu Clock runs as a SystemTask style task, drawing the time in the menu bar only when the application has asserted, by calling SystemTask, that it is okay to style a couple of cycles to do the drawing. Mac owners can see mult-tasking by going into an editor, and resizing the window to about half screen size. Bring up the KeyCaps desk accessory and put it beside your editor window. Click on the editor window and begin typing. KeyCaps tracks the state of the keyboard even when it is not the top window. (I have written 90% of a desk accessory that uses this technique to give a histogram of your instantaneous typing speed, recorded over the last 15 minutes, with numerical average speeds for the last 5 and 15 minuetes. When it is finished, I will post it.) Some things you can't do on a Mac: 1.) Time-slice Multitask two vanilla application programs. (Andy Hertzfeld said that he decided not to do it in Servant because the amount of task state you need to swap in the current applications makes the swap to slow.) (You can multi-task applications and desk accessories though. And there have been some pretty powerful desk accessories released: Click-On WorkSheet, MockWrite and MiniWrite, and Acta (an outline editor) spring to mind.) 2.) give tasks of the same class priorities. Withing the constraints of memory, you can have "w" applications active at once, "x" desk accessories, "y" vbl tim-slice tasks, and "z" device drivers. Are there any Amiga programmers who needed task priorities? If so, why ? I'm not trying to flame, I'm trying to learn. --- David Phillip Oster -- "We live in a Global Village." Arpa: oster@lapis.berkeley.edu -- Uucp: ucbvax!ucblapis!oster -- "You are Number Six."
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/29/86)
> In article <255@husc6.HARVARD.EDU> (mitsuharu hadeishi) writes: > Please correct me when I am wrong, but I'm under the impression that the > Amiga has both time-sliced multi-tasking and, a routine called Wait() hat > lowers the priority of an application. The application is supposed to > call Wait() when it has nothing to do. As I understand it, Wait() doesn't really change the task's priority, it simply relinquishes that processes's time slice. So I tell my program to Wait(), the 68000 goes out and does a round of the other tasks, which might include lower priority tasks. It gets back to me, checks the thing it waiting on, still waiting, and we go around again. > How do Amiga programmers handle continuous mouse tracking so their programs > can change the cursor shape as the cursor enters different kinds of > objects? This is normally handled by Intuition, which is in itself a process. It keeps track of all the mouse movements, and will switch the mouse pointer image for you if you change windows. A task can ask to be informed of all mouse movement, just a few specific mouse events (like clicking on certain gadgets, menu selections, or the case of that task's window becoming the selected window, etc.), or no mouse events at all. So really, the programmer has most of this done automatically, and since intuition and the input devices run as separate tasks, they can use the CPU time more efficiently and they don't get bogged down very easily. > My Menu Clock runs as a SystemTask style task, drawing the time in the > menu bar only when the application has asserted, by calling SystemTask, > that it is okay to style a couple of cycles to do the drawing. MY Menu Clock runs as a normal program (I usually send it off as a slightly lower priority process so if I get busy it won't slow me down). Its essentially a loop that reads the system clock, displays the time, and then usually Wait()s for a minute before looping. Every so often, when its awake, it will make sure its visible by pushing itself up as top window and maybe displaying the date or something. > Some things you can't do on a Mac: > 1.) Time-slice Multitask two vanilla application programs. (Andy Hertzfeld > said that he decided not to do it in Servant because the amount of task > state you need to swap in the current applications makes the swap to > slow.) (You can multi-task applications and desk accessories though. And > there have been some pretty powerful desk accessories released: Click-On > WorkSheet, MockWrite and MiniWrite, and Acta (an outline editor) spring to > mind.) There's no such thing as a "Desk Accessory" on an Amiga, everything's a process or a task. A process is a task with a bit more information that's needed to use the DOS; all tasks must talk to device drivers directly (no trouble, just a lower level of access than via DOS). All programs started from WorkBench or CLI are processess; thay may in turn start up tasks. > 2.) give tasks of the same class priorities. Withing the constraints of > memory, you can have "w" applications active at once, "x" desk accessories, > "y" vbl tim-slice tasks, and "z" device drivers. > Are there any Amiga programmers who needed task priorities? If so, why ? Priorities are useful mainly to set the importance of programs. I don't want my clock program to slow down a compilation or big calculation, so I give it a lower priority and it won't get any time if the time's not available. So it just hangs back and, as soon as the time is available, it gets updated. The Amiga custom chips help alot with multitasking, since whenever a task does a synchronous blitter, disk, sound, etc. operation, it will Wait(), the custom chip will do the operation via DMA, and the 68000 will have some free time for other tasks. > I'm not trying to flame, I'm trying to learn. I'm always learning, and trying to supply some intelligent answers here. > --- David Phillip Oster -- "We live in a Global Village." > Arpa: oster@lapis.berkeley.edu -- > Uucp: ucbvax!ucblapis!oster -- "You are Number Six." -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.
hadeishi@husc4.harvard.edu (mitsuharu hadeishi) (09/30/86)
From husc6!rutgers!caip!cbmvax!daveh Mon Sep 29 20:53:41 EDT 1986 Article 5219 of net.micro.amiga: Path: husc6!rutgers!caip!cbmvax!daveh >From: daveh@cbmvax.cbm.UUCP (Dave Haynie) Newsgroups: net.micro.mac,net.micro.amiga Subject: Re: Re: Task WAIT on a Mac Message-ID: <810@cbmvax.cbmvax.cbm.UUCP> Date: 29 Sep 86 18:37:35 GMT References: <1341@jade.BERKELEY.EDU> Organization: Commodore Technology, West Chester, PA Lines: 79 Xref: husc6 net.micro.mac:8482 net.micro.amiga:5219 In article <810@cbmvax.cbmvax.cbm.UUCP> Dave Haynie writes: >> In article <255@husc6.HARVARD.EDU> (mitsuharu hadeishi) writes: >> Please correct me when I am wrong, but I'm under the impression that the >> Amiga has both time-sliced multi-tasking and, a routine called Wait() hat >> lowers the priority of an application. The application is supposed to >> call Wait() when it has nothing to do. Whoa. Hold on there. Just to set the record straight, I did not write those words. Those words were in *response* to my words. (Hey, is there an echo in here? in here? in here?) -Mitsu (hadeishi@husc4.UUCP)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/30/86)
>As I understand it, Wait() doesn't really change the task's priority, >it simply relinquishes that processes's time slice. So I tell my program >to Wait(), the 68000 goes out and does a round of the other tasks, which >might include lower priority tasks. It gets back to me, checks the thing >it waiting on, still waiting, and we go around again. Wrong Wrong Wrong. Wait() is NOT implimented with a poll. When you Wait(), your process goes on a Wait queue and is never even glanced at again until some other process or interrupt signals it (manually or by sending a message to a signalling message port). When this happens, the process (actually called a Task on the amiga) is placed on the Ready queue (unless it's at high enough priority to warrent being run immediately OR if there are no other processes running.. somthing like that), Since only one task can be Run at a time, the Rest are 'Ready'. -Matt