ali@polya.STANFORD.EDU (Ali Ozer) (03/17/88)
In article <6970@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: >Here may be a big point that keeps getting missed. Apple is probably shyer >than they should be about Multifinder's real abilities. This pre-emption >issue vs. Unix seems just about pure eyewash -- the two systems look about >equally (non-)pre-emptive. > ... >Unix is not 'pre-emptive' at all, unless a process stays in it's own >computation longer than the 'lightning bolt' timer interrupt period, >which has traditionally been a 1 second interval. ^^^^^^^^ I'd hate to run any sort of interactive program on such a system, especially if anyone is ray-tracing! 8-) But really, there are some other features that Unix (and other multitasking systems provide) that you really do need. Task priorities, for instance. Consider the Amiga: You run a ray tracer and a word processor. Set the ray tracer's priority to a low value, and leave the WP at the default. You are assured of getting immediate response as soon as you hit any key in your WP, while the ray tracer (which we assume is a CPU hog) will soak up any unused cycles from right between your fingers. But you won't even know the ray tracer is running. Another feature you might find in a multitasking operating system is interprocess communication, which Multifinder currently doesn't provide. Interprocess communication isn't necessary for multitasking; but many problems are much more easily and gracefully solved with it than without it. Note that I'm not saying MultiFinder can't do these; with enough work anything is possible. You can kludge up you ray tracer and stick in calls to check the event queue. You'd need to put these in a lot places, though, as ray tracers tend to do off and run in floating point intensive loops for long periods of time. As soon as some event came in, the ray tracer would have to give up control. Interprocess communcation is also possible --- You can write and read files (whose names have been agreed on by the participating tasks), or you can use system resource files kept in RAM. Yes, these are possible, but probably at the cost of speed and memory. And not to mention all the redundancy in user programs. Ali Ozer, ali@polya.stanford.edu
goldman@Apple.COM (Phil Goldman) (03/18/88)
In article <2154@polya.STANFORD.EDU> ali@polya.UUCP (Ali Ozer) writes: >I'd hate to run any sort of interactive program on such a system, especially >if anyone is ray-tracing! 8-) But really, there are some other features that >Unix (and other multitasking systems provide) that you really do need. >Task priorities, for instance. Consider the Amiga: You run a ray tracer >and a word processor. Set the ray tracer's priority to a low value, and leave >the WP at the default. You are assured of getting immediate response as soon >as you hit any key in your WP, while the ray tracer (which we assume >is a CPU hog) will soak up any unused cycles from right between your fingers. >But you won't even know the ray tracer is running. > I think you have a point, but for a different reason. The only time you want the WP to have highest priority is when you are interacting with it. At all other times you want it to have the lowest priority. MultiFinder accomplishes this by guaranteeing highest priority to the application with the frontmost layer, at the expense of all other layers. However, when the WP is not frontmost, it gets no time at all and will never interrupt the ray tracer from its task. The only nicety in your example above is that *as soon as* you hit the key you get switched to the WP, but this is made possible because of preemption, not task priorities. Without preemption all the prioritization can't get the CPU to the WP's event handling code any quicker than MultiFinder does. One more point about prioritization is that it had better be dynamic (e.g. frontmost task vs. the rest in MF). Otherwise, priorities assigned in a vacuum will not work well with different task mixes. -Phil Goldman Apple Computer
ali@polya.STANFORD.EDU (Ali Ozer) (03/18/88)
In article <7731@apple.Apple.Com> goldman@apple.UUCP (Phil Goldman) writes: >I think you have a point, but for a different reason. The only >time you want the WP to have highest priority is when you are interacting >with it. At all other times you want it to have the lowest priority. >MultiFinder accomplishes this by guaranteeing highest priority to the >application with the frontmost layer, at the expense of all other >layers. However, when the WP is not frontmost, it gets no time at all >and will never interrupt the ray tracer from its task. > >One more point about prioritization is that it had better be dynamic >(e.g. frontmost task vs. the rest in MF). Otherwise, priorities assigned >in a vacuum will not work well with different task mixes. True. This of course is automatically obtained if tasks normally call a sleep() or wait() routine (WaitNextEvent()as opposed to polling-type GetNextEvent() under MF, correct?). On the Amiga all programs use the Wait() routine to wait for events (input/output/timer/disk/etc...) so you automatically have "dynamic" prioritization. Thus an high-priority WP will be fully asleep and consuming no CPU while not being used. But it'll be ready to wake up and jump at any instant, because of its high priority. (Of course, lack of virtual memory helps. 8-) No UNIX-like disk grinding when you switch back to your editor after an hour of non-use...) Ali Ozer, ali@polya.stanford.edu