tecot@apple.UUCP (08/19/87)
I'd like to dump on the net about a pet peeve of mine: "True Multitasking" has just about as much meaning as "Politically Correct" and "Standard Unix". In other words, it has no meaning. What most everyone means to say is "Pre-emptive Multitasking", that is, that the processor can be yielded to another process at any time. For my sake, please refrain from using that other term. And now for my more "direct" comments: Yes, MultiFinder is being billed as the first generation multitasking O/S for the Macintosh. And it is, in fact, multitasking. It is not (currently) pre-emptive. However, for Macintosh, this is not important. All standard Macintosh applications already yield when MultiFinder is running. No changes needed. Applications only need to be changed for two basic reasons: 1) Applications which do dirty tricks such as modifying the window list directly 2) Applications which want to be "MultiFinder friendly" will use WaitNextEvent instead of GetNextEvent to allow MultiFinder to allow do its job better. >The important point about time-slicing is that it allows virtually *any* >two (or more) programs to multitask WITHOUT requiring even one "trivial >code change." Thus, on a system with time-slicing, a Kermit download >will co-operate with an editor quite nicely (especially if Kermit is >running at a lower priority). The editor will suffer no response >degradation, while Kermit will run quickly almost all the time (editors >usually spend a lot of time waiting for keystrokes. . .). This should work on the Mac as well. The reason: If Kermit provides any way to cancel the download, it is automatically ceding control. Now I must admit that some "trivial" changes are required, but they exist only because several Mac applications (incorrectly) made the assumption that they would have full control and do strange things like animating the cursor. Although such applications will run, they will look wierd and confuse the naive user. All that is required is to place a resource in the application (no need to recompile or even have the source code) so that MultiFinder will know that it is not one of those "wierd" applications. >The time savings from eliminating three enormous writes to disk and three >correspondingly enormous reads from disk are tremendous. Also, on small >systems, there may not be enough mass storage to hold all the intermediate >forms at once. Thus, the user would have to delete intermediate files >between steps, or operate from one disk to another (or both!). On my >Amiga, which has two floppy disk drives and no hard disk, this would tie >up the system completely, as well as requiring my intervention at several >places in the process. But with the pipelined version, I would need to >use only one disk (for output), so the second drive is freed for other >purposes. Great. I think most of us are familiar with pipes and can see their benefit. But pipes does not a multitasking system make. It is related to a different sub-topic: inter-process communication. Please don't confuse the two. >Further, because of the multitasking, I can still do a compilation in >the background *and* edit a file while all this is going on! (This >assumes that I have boatloads of memory, of course. . .) With process >priorities chosen carefully (e.g., editor priority > download, etc. >priority > compilation priority), the editor will be responsive, >the download and associated processing will perk right along (limited >mainly by the phone line data rate), and the compilation will use up >whatever is left of the CPU. On a Macintosh, these priorities are automatic, the user doesn't have to carefully do anything. >This is just one example of enhanced productivity and system utility >provided by true multitasking. None of the programs that are running >need to know or do anything out of the ordinary in order to multitask. Instead, the user takes the burden. None of the programs that are running need to know or do anything out of the ordinary in order to multitask on MultiFinder either, it just so happens that some applications do things out of the ordinary that prevent them from running cleanly in the background. >Because it puts the responsibility for task switching on the programs >themselves, so-called "synchronous multitasking" only works with programs >designed to permit task switching. But almost all of them do. >Compared to true multitasking, >"synchronous multitasking" is a feeble and limited technique. Where's the proof? I contend that synchronous multitasking is more efficient, provided that the synchronization is transparent to the process (which is true for MultiFinder). _emt
sysop@stech.UUCP (Jan Harrington) (08/20/87)
in article <1500@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) says: > > I'd like to dump on the net about a pet peeve of mine: "True Multitasking" > has just about as much meaning as "Politically Correct" and "Standard Unix". > In other words, it has no meaning. What most everyone means to say is > "Pre-emptive Multitasking", that is, that the processor can be yielded to > another process at any time. For my sake, please refrain from using > that other term. > > And now for my more "direct" comments: > > Yes, MultiFinder is being billed as the first generation multitasking O/S > for the Macintosh. And it is, in fact, multitasking. I'd like to add a few random comments about what appears to be an ongoing argument between Amiga and Mac people about multi-tasking. I'm am avid Mac person who used to own an Amiga but sold it in frustration. I work with someone who has an Amiga, and according to him, the machine can do no wrong. He believes that its operating system is more like those he worked with at MIT some years ago; it's very low level. Programming it requires much more attention to system details than programming on the Mac. (See my article in the January 1987 Dr. Dobb's Journal if you want the deep dirty details ...). Developers on the Mac, if they adhere to Apple's guidelines (those 10 or so points that they shipped to developers not so long ago), don't need to worry about MultiFinder details. Who cares if its not "pre-emptive" multi-tasking at this point? For the user, MultiFinder will allow multiple applications to run in multiple windows. That's exactly what we need and want. For the developer, it adds virtually no complexity to the development process. Amiga people should stop taking pot shots. The Mac and Amiga development environments are totally different. If you like working with message ports then program on the Amiga; it you prefer to be isolated from such low level device interaction, then work with the Amiga. I prefer the Mac, but I suppose there's room in this world for both ... Jan Harrington, sysop Scholastech Telecommunications seismo!husc6!amcad!stech!sysop
cbenda@unccvax.UUCP (carl m benda) (08/21/87)
In article <1500@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: > Yes, MultiFinder is being billed as the first generation multitasking O/S > for the Macintosh. And it is, in fact, multitasking. It is not (currently) Please answer this question SOMEBODY: To me, multitasking means: multiple tasks running concurrently having the appearance of multiple machines running simultaneously.. with the MULTI-FINDER can I: Compile a 268K C program in a window and Use Macterminal to down load a 220k binary file and Repaginate my 235 page thesis and play a game of chess all in their own respective windows, and all simultaneously.. Can I do this? Assume of course I have a 6Megabyte Mac II a 20 inch display, and a Hayes modem. Can Multi-finder handle this???? If not then its not a big step beyond switcher. /Carl ....decvax!mcnc!unccvax!cbenda
jackie@apple.UUCP (Hernan'Jackie' Macapanpan) (08/21/87)
In article <798@unccvax.UUCP>, cbenda@unccvax.UUCP (carl m benda) writes: > In article <1500@apple.UUCP>, tecot@apple.UUCP (Ed Tecot) writes: > > Yes, MultiFinder is being billed as the first generation multitasking O/S > > for the Macintosh. And it is, in fact, multitasking. It is not (currently) > > > Please answer this question SOMEBODY: > > To me, multitasking means: > > multiple tasks running concurrently having the appearance of multiple > machines running simultaneously.. > > with the MULTI-FINDER can I: > > Compile a 268K C program in a window > and > Use Macterminal to down load a 220k binary file > and > Repaginate my 235 page thesis > and > play a game of chess > all in their own respective windows, Yes, assuming you've got memory (6Mega is more than enuf). > and all simultaneously.. Not yet. > Can Multi-finder handle this???? > If not then its not a big step beyond switcher. Presently, MultiFinder lets users view multiple applications concurrently and copy, paste and move rapidly between applications within the Mac environment. With the appropriate hardware, MultiFinder makes it possible to concurrently work in and integrate info between multiple operating systems, including MS-DOS. (Now who would wanna do that. hee hee). Currently, only printing can be done in the background, however, a variety of new applications are being developed (email, file processing, terminal emulation, etc) which will take advantage of MultiFinder's ability to perform functions in the background. Thus, these functions can be executed while the user works on other applications. Multitasking. Jackie Disclaimer: Apple takes no responsibility for me, I cross the street all by myself, I know how to make change. I don't know how to type, these things just start appearing on my terminal. |-).
keithd@cadovax.UUCP (Keith Doyle) (08/23/87)
In article <798@unccvax.UUCP> cbenda@unccvax.UUCP (carl m benda) writes: >with the MULTI-FINDER can I: > > Compile a 268K C program in a window > and > Use Macterminal to down load a 220k binary file > and > Repaginate my 235 page thesis > and > play a game of chess >all in their own respective windows, and all simultaneously.. The impression I got is that it can, but only effectively if whoever wrote the C compiler (and probably the chess program) remembered to put SWAP()'s or WAIT()'s (or whatever causes a task to relinquish control) periodically throughout compute-bound portions of the code. Otherwise the rest of the programs can experience significant pauses when a compute-bound task ends up hogging the PC and won't give other tasks a chance to run. If I've gotten the wrong impression, feel free to correct me. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa Contel Business Systems 213-323-8170
gary@eddie.MIT.EDU (Gary Samad) (08/28/87)
}Amiga people should stop taking pot shots. The Mac and Amiga development }environments are totally different. If you like working with message ports }then program on the Amiga; it you prefer to be isolated from such low level ^^^^^ }device interaction, then work with the Amiga. ^^^^^ Interesting Freudian Slip, eh? :-)