norman@d.cs.okstate.edu (Norman Graham) (08/03/90)
[Sorry about the previous article; 'rn' thought it belonged to someone
else and it wouldn't let me cancel it.]
With System 7.0 just around the corner (the corner of 1990 that is :-),
I'm inclined to observe the following paradox: While System 7.0 will not
provide true multitasking (tm), it will provide inter-application
communication.
Obviously, if you don't have true multitasking you can't possibly have
true IAC: After all, what can a process communicate with if no other
process is truly running at the same time? Is some Apple marketing type
trying to pull the wool over our eyes or what? Come on ye keepers of the
true multitasking faith,let's rise up and squash this IAC propoganda.
Many :-)'s
Norm
--
Norman Graham Oklahoma State University
Internet: norman@a.cs.okstate.edu Computing and Information Sciences
BangPath: 219 Mathematical Sciences Building
{cbosgd,rutgers}!okstate!norman Stillwater, OK USA 74078-0599Gavin_Eadie@um.cc.umich.edu (Gavin Eadie) (08/04/90)
In article <1990Aug3.040513.14844@d.cs.okstate.edu> norman@d.cs.okstate.edu (Norman Graham) writes: > Obviously, if you don't have true multitasking you can't possibly have > true IAC: After all, what can a process communicate with if no other > process is truly running at the same time? Even with "true multitasking" no other process is "truly running" at the same time unless you are using a multiprocessor computer and, even then, the process running on the receiver is the one catching the IAC and not the application itself. This is a silly topic to be wasting energy on ...
baumgart@esquire.dpw.com (Steve Baumgarten) (08/06/90)
In article <1990Aug3.040513.14844@d.cs.okstate.edu>, norman@d.cs (Norman Graham) writes: >Obviously, if you don't have true multitasking you can't possibly have >true IAC: After all, what can a process communicate with if no other >process is truly running at the same time? Is some Apple marketing type >trying to pull the wool over our eyes or what? Come on ye keepers of the >true multitasking faith,let's rise up and squash this IAC propoganda. > >Many :-)'s >Norm Assuming you meant the smileys for the "rise up" part of your message, and not necessarily the first part... One of the most overlooked features of System 7 is its ability to handle IPC without requiring both programs to be running at the same time. For people who just want to get their work done in the best and most convenient way (i.e., people working in groups, each contributing something to a final document, or various people receiving live updates from a spreadsheet that's maintained in another department), this is a major advance in OS design. Being able to have a socket or shared memory under Unix, or taking advantage of DDE under Windows is fine -- assuming that you want to keep all the relevant programs running at the same time. But Apple's publish/subscribe method of IPC makes much more sense, since it allows documents to make available certain parts of themselves to anyone on the network who is interested in making use of them. The application that created the document does not have to be running or even present on the system for this to work. There's nothing like this (that I'm aware of) in the Unix world, and I don't think there's any support for it under Windows or OS/2 (please correct me if I'm wrong). Although the Mac still doesn't support "true" multitasking or "true" IPC, it seems that the multitasking and IPC it *does* offer provides real benefits to real users -- even though Apple's definitions of multitasking and IPC may not make CS majors happy. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." baumgart@esquire.dpw.com | cmcl2!esquire!baumgart | - David Letterman
Patrick.Hayes@cediag.bull.fr (Patrick Hayes) (08/13/90)
In article <1990Aug3.171847.3222@terminator.cc.umich.edu> Gavin_Eadie@um.cc.umich.edu (Gavin Eadie) writes: >norman@d.cs.okstate.edu (Norman Graham) writes: >> Obviously, if you don't have true multitasking you can't possibly have >> true IAC: After all, what can a process communicate with if no other >> process is truly running at the same time? > >Even with "true multitasking" no other process is "truly running" at the >same time unless you are using a multiprocessor computer and, even then, >the process running on the receiver is the one catching the IAC and not >the application itself. > >This is a silly topic to be wasting energy on ... Agreed, but in the spirit of the original question: Will Mac IPC be limited to the same CPU or are other macs IPCable? Pat -- +-------------------------------+-----------------------------------------+ | Patrick Hayes | EMail : Patrick.Hayes@cediag.bull.fr | | BULL CEDIAG | or hayes@bull.fr | | 68, Route de Versailles | or ...!mcvax!inria!bullfr!hayes | | F-78430 Louveciennes FRANCE | Tel : (33 1) 39 02 49 55 | +-------------------------------+-----------------------------------------+
dwal@ellis.uchicago.edu (David Walton) (08/14/90)
In article <PATRICK.HAYES.90Aug13153815@sky.cediag.bull.fr> Patrick.Hayes@cediag.bull.fr (Patrick Hayes) writes: > >Agreed, but in the spirit of the original question: >Will Mac IPC be limited to the same CPU or are other macs IPCable? You can use IAC to communicate across a network. The IAC architecture in System 7.0 is designed to be used pretty much the same way for either the local machine or another machine on the network (with some differences depending on which layer of IAC you use). For example, an application could use a dictionary application on either the local machine or on a remote machine in pretty much the same way. Of course, IAC can also be disabled by the user with a checkbox in an application's Get Info window; an application must also have the appropriate bits set in its SIZE resource to get IAC. >Pat -- David Walton Internet: dwal@midway.uchicago.edu University of Chicago { Any opinions found herein are mine, not } Computing Organizations { those of my employers (or anybody else). }
daven@svc.portal.com (08/16/90)
In article <PATRICK.HAYES.90Aug13153815@sky.cediag.bull.fr> Patrick.Hayes@cediag.bull.fr (Patrick Hayes) writes: >Will Mac IPC be limited to the same CPU or are other macs IPCable? Yes! However, the user will have the choice of allowing other Macs on the LAN to "chat" with their local applications and system. -- Dave Newman - Sofware Ventures | daven@svc.portal.com | AppleLink: D0025 Berkeley, CA (415) 644-3232 | AOL: MicroPhone | CIS: 76004,2161 -------------------------------------------------------------------------------
chewy@apple.com (Paul Snively) (08/16/90)
In article <PATRICK.HAYES.90Aug13153815@sky.cediag.bull.fr> Patrick.Hayes@cediag.bull.fr (Patrick Hayes) writes: > Will Mac IPC be limited to the same CPU or are other macs IPCable? Our IPC suite is network capable. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
ngg@bridge2.ESD.3Com.COM (Norman Goodger) (08/17/90)
In article <1990Aug3.040513.14844@d.cs.okstate.edu> norman@d.cs.okstate.edu (Norman Graham) writes: > >With System 7.0 just around the corner (the corner of 1990 that is :-), >I'm inclined to observe the following paradox: While System 7.0 will not >provide true multitasking (tm), it will provide inter-application >communication. >Obviously, if you don't have true multitasking you can't possibly have >true IAC: After all, what can a process communicate with if no other >process is truly running at the same time? Is some Apple marketing type >trying to pull the wool over our eyes or what? Come on ye keepers of the >true multitasking faith,let's rise up and squash this IAC propoganda. > Despite the -:)'s, I say there is no such thing as "True MultiTasking", you either have "pre-emptive" or "cooperative" MultiTasking. Take your pick... Pre_emptive Multitasking I suspect will slow down performance of current Mac's to much to be acceptable. Users here are to speed minded to allow a wait till something decides to give you time to do what you want when it wants to not you (that make sense?) Lets stamp out the True-MultiTasking rumor...there is no such thing. -:) -- -- Norm Goodger SysOp - MacInfo BBS @415-795-8862 3Com Corp. Co-SysOp FreeSoft RT - GEnie. Enterprise Systems Division (I disclaim anything and everything) UUCP: {3comvax,auspex,sun}!bridge2!ngg Internet: ngg@bridge2.ESD.3Com.COM
murat@farcomp.UUCP (Murat Konar) (08/18/90)
Gawd, not this true vs. fake multi-tasking debate again! -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/20/90)
In article <2760@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman Goodger) writes: > > Despite the -:)'s, I say there is no such thing as "True > MultiTasking", you either have "pre-emptive" or "cooperative" > MultiTasking. Take your pick... Actually, you either have pre-emptive multitasking, or you have nothing. Taking it your way, my Apple II has cooperative multitasking since it allows me to load two specially written executables at two different locations, which then branch into each other when they have completed part of their task. Of course the Mac has much more built-in support for such a cooperative effort, but multitasking is not a feature which can be quantitized. Either you have it, or you don't. An operating system has a pre-emptive scheduler, or it doesn't have one at all. There is no such thing as a cooperative scheduler. The term cooperative is used when there is an absence of a scheduler. > Pre_emptive Multitasking I suspect will slow down performance > of current Mac's to much to be acceptable. You misunderstand the concepts behind (pre-emptive) multitasking. The idea is to have the kernel interrupt the task in progress if another task of a higher priority is ready to run or if the quantum of the current one is over. If there is no other other task ready to run, task switching never occurrs. Therefore, whether each task is responsible for lanching cooperatively other tasks, or whether the operating system does that, has nothing to do with the speed at which these tasks will run. Factors which could affect the speed are 1. the size of the time slice (quantum) 2. overhead of the dispatcher 3. the memory model (independent or common address spaces, memory protection, virtual memory, etc.) If anything, a preemptive operating system will be faster, because it will perform task switching only when necessary. The preemptive operating system will also allow the user to set task priorities. Thus if the user wants task B to run only when task A is waiting for an event to complete, all it has to do is lower its priority below that of task A. Such is the nature and purpose of preemtive schedulers. > Lets stamp out the True-MultiTasking rumor...there is no such thing. Thank you for your support. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
chewy@apple.com (Paul Snively) (08/21/90)
In article <13888@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > An operating system has a pre-emptive scheduler, or it doesn't > have one at all. There is no such thing as a cooperative scheduler. The term > cooperative is used when there is an absence of a scheduler. Wrong. It's quite possible to have a cooperative scheduler; all it means in the case of the Macintosh is that some events are of higher or lower priorities than others (for example, in the forthcoming System 7.0 release, High-Level Events will have a higher priority than user-initiated events, so that AppleEvent throughput will be at an acceptable level). Of course, in a cooperative environment, each "cooperating" entity still has the opportunity to be rude and be a CPU hog; the cooperative scheduler simply means that once the hog _does_ relinquish control, it may be a while before it gets control back again, and how long "a while" is depends partially upon the scheduler and partially upon just how cooperative everything else running is being. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
jay@argosy.UUCP (Jay O'Conor) (08/21/90)
In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <2760@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman >Goodger) writes: >> >> Despite the -:)'s, I say there is no such thing as "True >> MultiTasking", you either have "pre-emptive" or "cooperative" >> MultiTasking. Take your pick... > >Actually, you either have pre-emptive multitasking, or you have nothing. Taking >it your way, my Apple II has cooperative multitasking since it allows me to >load two specially written executables at two different locations, which then >branch into each other when they have completed part of their task. Hmmm. I strongly disagree with this. Both pre-emptive and cooperative multitasking are valid implementations of multitasking. Why does it make any difference whether or not a task-switch occurs off a clock tick interrupt? As long as the O/S will allot time to other tasks without the knowledge of other tasks, then multitasking is achieved. On the Mac, task switches take place at Get/WaitNextEvent and EventAvail. These O/S calls are not made for the explicit purpose of relinquishing the processor, but instead to get operator input. Gee, I would hope that any multitasking system would take advantage if the time spent waiting for input to run other tasks. > >Of course the Mac has much more built-in support for such a cooperative effort, >but multitasking is not a feature which can be quantitized. Either you have it, >or you don't. An operating system has a pre-emptive scheduler, or it doesn't >have one at all. There is no such thing as a cooperative scheduler. The term >cooperative is used when there is an absence of a scheduler. I only partially disagree here. Even in a cooperative multitasking system, priority scheduling can take place. Just not time scheduling. The cooperative 'scheduler' still is responsible for choosing the next task to run. It may implement a simple round-robin policy, or any priority scheme the O/S designer chooses. If this is not a scheduler, what would you call it? > >> Pre_emptive Multitasking I suspect will slow down performance >> of current Mac's to much to be acceptable. > >You misunderstand the concepts behind (pre-emptive) multitasking. The idea is >to have the kernel interrupt the task in progress if another task of a higher >priority is ready to run or if the quantum of the current one is over. If there >is no other other task ready to run, task switching never occurrs. I agree 100% here. Although an argument could be made that the overhead of the clock interrupt handler having to check for a new task to run could be significant. In the case of the Mac, there's so many things that already occur at interrupt time I would suspect that checking for a new task to run wouldn't be much more. > >Therefore, whether each task is responsible for lanching cooperatively other >tasks, or whether the operating system does that, has nothing to do with the >speed at which these tasks will run. Factors which could affect the speed are > >1. the size of the time slice (quantum) >2. overhead of the dispatcher >3. the memory model (independent or common address spaces, memory protection, > virtual memory, etc.) > >If anything, a preemptive operating system will be faster, because it will >perform task switching only when necessary. The preemptive operating system >will also allow the user to set task priorities. Thus if the user wants task B >to run only when task A is waiting for an event to complete, all it has to do >is lower its priority below that of task A. Some disagreement here again. I agree that number 1 and 2 above do have a lot to do with the performance of any individual task. I don't believe that number 3 has much to do with performance other than the presence/absence of virtual memory. Obviously, page swapping can impact performance, but how can common vs. seperate address spaces, memory protection affect performance? I don't believe that loading MMU registers can have much impact on performance. Granted that MMU cache entries will likely be invalid after a task switch, but then most (if not all) locality of reference is lost on any task switch, be it cooperative or pre-emptive. This shows another area that could be argued (but I believe it's not a valid argument). Higher _system_ performance could be gained by not doing pre-emptive task switching, since the processor cache hit rate should be higher if a task is allowed to run until it can't anymore (due to I/O needs). The cache could be unnecessarilly made invalid (due to losing the locality of reference) by pre-emptive task-switching. Just some more fuel to add to the multi-tasking fire. Seriously though, I really wish people weren't so hung up on pre-emptive multitasking. I agree it's the way to go on the Mac (in the future), but people should recognize that cooperative multitasking is a perfectly legitimate method of multitasking. There is only one reason for implementing cooperative multitasking - when the process state can only be known at certain times. This is the case with the current Mac O/S. When Apple is able to better define process state, either by keeping all process state information in one place, or by providing a virtual machine capability, that's when we'll see pre-emptive multitasking on the Mac. Jay O'Conor jay@maspar.com
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/21/90)
In <13888@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) makes a couple of misleading comments: "There is no such thing as a cooperative scheduler." Yes there is--it's called MultiFinder (or the Process Manager under System 7). It's the bit of code that decides which process gets to run next when the current process calls Get/WaitNextEvent. If that isn't scheduling, I don't know what is. "a preemptive operating system will be faster, because it will perform task switching only when necessary." Not quite true. A *non-time-sliced* preemptive operating system will perform task switching only when necessary. A time-sliced scheduler is liable to cause lots of unnecessary task switches under conditions which I expect to be quite common on a single- user system. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 This week: featuring a visit from famous gambler and socialite, Lady Moneydown.
kenk@tellabs.com (Ken Konecki) (08/21/90)
In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Actually, you either have pre-emptive multitasking, or you have nothing... >An operating system has a pre-emptive scheduler, or it doesn't >have one at all. There is no such thing as a cooperative scheduler. The term >cooperative is used when there is an absence of a scheduler. If I understand the point your trying to make, you're saying that in order to be multitasking, an OS must provide a scheduler. Why must there be a software scheduler? Under the multifinder implementation of multitasking, the user is the scheduler. It's pretty much the same effect as a software scheduler, but it makes no presumptions about what the user intends. The user is the one responsible for assigning priorities to his/her tasks and changing them as necessary. >If anything, a preemptive operating system will be faster, because it will >perform task switching only when necessary. Apparently you have never used a Sun. There have been countless times that I have pushed ye olde mouse button and waited for *seconds* for the wonderful preemptive OS to respond to the input. And I'm not the only one making this complaint. Cheers, -Ken K -- Ken Konecki "Eat well, stay fit, and die anyway" e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188
mneerach@c.inf.ethz.ch (Matthias Ulrich Neeracher) (08/22/90)
In article <652@argosy.UUCP> jay@idiot.UUCP (Jay O'Conor) writes: >In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >>In article <2760@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman >>Goodger) writes: >>> Pre_emptive Multitasking I suspect will slow down performance >>> of current Mac's to much to be acceptable. >>You misunderstand the concepts behind (pre-emptive) multitasking. The idea is >>to have the kernel interrupt the task in progress if another task of a higher >>priority is ready to run or if the quantum of the current one is over. If there >>is no other other task ready to run, task switching never occurrs. >I agree 100% here. I don't think preemptive multitasking necessarily slows down performance, but if a scheduler is not very clever, it can hurt responsiveness. I'm sometimes working on Suns and trying to get a command from a nested pop-up menu can be a real pain on some of the slower window systems. MultiFinder, on the other hand, tends to favor the front application and therefore it appears to react quicker. Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
kraig@biostr.biostr.washington.edu (Kraig Eno) (08/22/90)
In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Actually, you either have pre-emptive multitasking, or you have nothing... >An operating system has a pre-emptive scheduler, or it doesn't >have one at all. There is no such thing as a cooperative scheduler. The >term cooperative is used when there is an absence of a scheduler. I agree with this definition of multitasking more than the others that have been flying around here. MultiFinder on a Mac just isn't doing multitasking if any user process can hog the machine for an arbitray length of time. The beauty of a multitasking machine is that several things can appear to be going on at once -- whatever scheduling system is in use, you should be able run compute-intensive jobs and continue with some unrelated task without having to wait for them to finish. "Cooperative" multitasking is meaningless because most normal applications don't cooperate. Two examples: (1) If a HyperCard script starts in and you decide you don't want to wait, you're stuck; with true multitasking, you should be able to just click on another application window and do something else for a while. HyperCard shouldn't have to jump hoops to allow you to do this; with a multitasking environment, the capability is inherent. (2) Try using Word on a long doc and doing a lengthy Change command. Word is nice: it lets you go off and do something else in the middle. But does the Change command continue processing and eventually finish while you're off reading netnews? No way. A workstation like the NeXT will do this sort of thing. Now, I've never used a window system on ANY Unix machine that is as responsive as Multifinder, but the Mac is NOT multitasking. Kraig Eno kraig@biostr.washington.edu
ewm@mdavcr.UUCP (Eric W. Mitchell) (08/22/90)
In article <13888@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Actually, you either have pre-emptive multitasking, or you have nothing. Taking >it your way, my Apple II has cooperative multitasking since it allows me to >load two specially written executables at two different locations, which then >branch into each other when they have completed part of their task. This is a rather poor example. A hard coded, explicit branch between two pieces of code is hardly what happens in "cooperative multitasking". >Of course the Mac has much more built-in support for such a cooperative effort, >but multitasking is not a feature which can be quantitized. Either you have it, >or you don't. An operating system has a pre-emptive scheduler, or it doesn't >have one at all. There is no such thing as a cooperative scheduler. The term >cooperative is used when there is an absence of a scheduler. In both "preemptive" and "cooperative" multitaskers, there is a piece of system code that priortizes and hands control to running processes based on some internal criterion. The only significant difference is that preemptive systems can interrupt execution of a process and cooperative systems can not. Cooperative systems rely on the process to return control to the scheduler in a "reasonable time". You will note that most (or perhaps all) preemptive multitaskers support some kind of ability to turn off the preemptive ability of the scheduler while running certain processes; for example, timing-critical applications, system routines, etc. Effectively, the scheduler becomes a *cooperative* multitasker until the process ends, and gives control back to the scheduler. In fact, the scheduler itself is effectively a "cooperative" task, handing control to other software in the system when it is good and ready. Real time systems in particular usually include some ability to lock out "preemption". Both preemptive and cooperative multitaskers have their advantages. Preemptive systems are typically less reliant on good programming habits of the software developers. >You misunderstand the concepts behind (pre-emptive) multitasking. The idea is >to have the kernel interrupt the task in progress if another task of a higher >priority is ready to run or if the quantum of the current one is over. If there >is no other other task ready to run, task switching never occurrs. You obviously have a good understanding of how preemptive multitasking works, but I think your rather dogmatic denial of other flavors of multitasking is somewhat silly. Multiple types of multitasking have been around for years. It is widely acknowledged and accepted (my university certainly did, anyway). Go ahead and argue the relative merits of various multitasking schemes, but don't deny that the others even exist! >If anything, a preemptive operating system will be faster, because it will >perform task switching only when necessary. The preemptive operating system >will also allow the user to set task priorities. Thus if the user wants task B >to run only when task A is waiting for an event to complete, all it has to do >is lower its priority below that of task A. *bzzzzzt* Wrong. A preemptive system will often be more *responsive*, but it is not *faster*. Actually, the word I think you should have used here is "more efficient", because you were arguing about system overhead due to task switching. However, you are basically incorrect anyway because preemptive multitasking slows down the system because it adds to the number of cycles required to perform a given operation. In this area, cooperative multitaskers are usually more efficient than preemptive systems. This is because a cooperative multitasker lets go only at suitable times. Thus instead of being preempted in the middle of a loop of calculations, a program will wait until a more appropriate point in the code - such as while waiting for I/O - to release control back to the scheduler. In general, this results in better utilization of CPU cycles. A preemptive system can certainly do this as well, but if the code does any operations where it has to wait for resources, execution becomes less efficient. Consider if the scheduler preempts an operation just before it makes a request for some resource - a task switch is made, then when control is returned to the process, the resource request is made and the scheduler must switch applications *again*. Two task switches where one would have been performed in a cooperative system. A general rule (that many others may not agree with) is that a cooperative scheduler is fine for systems that involve a lot of I/O, and a preemptive scheduler is better if you are running a lot of batch programs. Cooperative multitaskers are NOT suitable for many systems, whereas you could probably use a preemptive multitasker wherever you put a cooperative system. In the later case, you may actually suffer a performance drop, but it all depends on the system configuration. I certainly wouldn't put a cooperative multitasker in a multi-user system. I also wouldn't want one on a development system (too subject to programmer errors). But that's my opinion only. >Thank you for your support. > >Valentin Don't be a smart-a**. Eric ============================================================================== Disclaimer: PAY me for my advice, then I will take responsibility for it. Thus I am responsible to my company, but they are not responsible for me. --------- "Hmmm, MacDonalds? A&W? Hey! Kentucky Fried!!!" - Wiley Coyote gets smart
daveo@Apple.COM (David M. O'Rourke) (08/22/90)
kraig@biostr.biostr.washington.edu (Kraig Eno) writes: >A workstation like the NeXT will do this sort of thing. Now, I've never >used a window system on ANY Unix machine that is as responsive as >Multifinder, but the Mac is NOT multitasking. There are several example of multitasking system that aren't pre-emptive. Lots of early computer OS's did the context switch off of some/all system calls or other non-preemptive mech. I've yet to find an OS book that doesn't mention co-operative multi-tasking as a scheduling mech. Multi-tasking _STRICTLY_ defined is the running of more than one process at a time. Well to do that you need a CPU for each process. So any single CPU system is not a multi-tasking system. Or when ever you get n+1 processes going on an n-processor system then you no longer have a multi-tasking system. This must be the about the 100th time I've been drawn into this debate. Seems to happen about every three months. Multi-tasking as defined by most OS books is the ability to schedule the processor to do more than one thing without the current process running to completion. Multi-finder saves and restores context, and does do some limited scheduling of the processor resource. Therefore multi-finder is a multi-tasking extension of the Macintosh OS. Just because the scheduling method doesn't do it the way most bigger OS's do it doesn't remove the ability. There is more than one way to multi-task a system, and there will always be debate regarding which way is best. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
barnett@grymoire.crd.ge.com (Bruce Barnett) (08/22/90)
In article <3474@tellab5.tellabs.com> kenk@tellabs.com (Ken Konecki) writes: > >If anything, a preemptive operating system will be faster, because it will > >perform task switching only when necessary. > > Apparently you have never used a Sun. There have been countless times that > I have pushed ye olde mouse button and waited for *seconds* for the > wonderful preemptive OS to respond to the input. And I'm not the only > one making this complaint. Don't confuse context switching with swapping. All Sun's have hardware registers to support 8 context switches. If you have waited seconds, it is because your process was swapped out to disk and had to be read back into memory from remote disks. Most Sun's are effectively running diskless. A somewhat equivalent Mac configuration would be running System 7, 32 megabytes of virtual memory, and all executables mounted through AppleShare or TOPS volumes. If the Sun was diskless, then the equivalent Mac configuratioon would be floppy based. I recall context switching taking more than a few seconds with a floppy based Mac running Finder. :-) -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
PAT@rcgl1.eng.ohio-state.edu (Patrick Plaisted) (08/23/90)
| | >If anything, a preemptive operating system will be faster, because it will | >perform task switching only when necessary. | | Apparently you have never used a Sun. There have been countless times that | I have pushed ye olde mouse button and waited for *seconds* for the | wonderful preemptive OS to respond to the input. And I'm not the only | one making this complaint. | Even having never seen your hardware setup, I'd bet the mouse delays you're seeing are due to paging and having nothing to do with pre-emptive scheduling. If you're trying to run X11R4, emacs, and a couple of xterm windows on anything less than 8 megs of memory then you're waiting on things to be brought back off of disk, not the scheduler playing games with you. If on the other hand you have plenty of memory but you're compiling the latest versions of nethack and conquer in the backround while trying to work interactavely then it's more understandable. You can hardly blame the scheduler for doing it's job and giving those backround jobs equal footing for cputime. If you want faster response in the foreground, lower the priorities of the jobs in the backround. Even if it does slow things down some on the Sun try starting up a kermit download, fire up your C compiler on a big program, and then try to puruse a file in msword on your Mac. It ain't gonna happen. It's very hard to write complicated software programs that have to bend over backwards in order to please cooperative multi-tasking so that foreground jobs feel responsive. VERY HARD... | Cheers, | -Ken K | -- | Ken Konecki | "Eat well, stay fit, and die anyway" | e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk | U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188 =========================================================================== Patrick Plaisted |pat@agvax2.ag.ohio-state.edu System Programmer | or if you want to Ohio Cooperative Extension Service | torture me with unix: The Ohio State University |pat@klingon.eng.ohio-state.edu 2120 Fyffe Rd. Room #109 | Columbus, Ohio 43210 | (614) 292-4338 =========================================================================== I'm not quite sure who's ideas these are; I think they're mine...
mneerach@a.inf.ethz.ch (Matthias Ulrich Neeracher) (08/23/90)
In article <6588@milton.u.washington.edu> kraig@biostr.biostr.washington.edu (Kraig Eno) writes: > "Cooperative" multitasking is >meaningless because most normal applications don't cooperate. Some of them do, and I expect they are getting more and more. What I use very often is to read the Inside Mac VI or the Tech Note Stack in HyperCard while MPW compiles in the background. Also, most compaction and archival programs seem already able to be running in the background. It is true that few applications currently can run in the background. What also seems to be very important to me, however, is that about 95% of current applications give time to applications running in the background. So, the problem is not that nobody cooperates but that nobody uses the cooperation. Matthias ----- Matthias Neeracher mneerach@c.inf.ethz.ch "I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me" -- Hunter S. Thompson
kraig@biostr.biostr.washington.edu (Kraig Eno) (08/23/90)
In article <923@mdavcr.UUCP> Eric W. Mitchell writes: > Preemptive systems are typically less reliant on good programming habits > of the software developers. I think you are saying that the developers should make their programs "multifinder-aware", because if they ignore the issue entirely then their programs won't appear to function well when run simultaneously with other programs. You have put your finger squarely on the issue under discussion. All the stuff about scheduling algorithms and performance is a side issue; the point in question (which so far hasn't been well specified) is whether "true multitasking" should or should not require cooperation by the individual user programs. I am not going to post to the net any more on this issue, because there are just too many people talking about too many different things and bringing it all under the heading of "multitasking". The big problem is that everyone is right about what they are saying, basically. If you think a developer SHOULD have to worry about the issue when writing his program and that's what you call multitasking, then OK. I was taught that a multitasking system should take care of task switching for you -- the programmer shouldn't have to make some non-portable system call every millisecond to make sure his program will allow others to run simultaneously. It all takes a lot of work under MultiFinder, and I don't call that multitasking.
Chris.Parson@f54.n382.z1.FIDONET.ORG (Chris Parson) (08/24/90)
The Mac does SOME multitasking. As I write this, Strategic Conquest is playing the computer's "turn" in the background. I often play SC while downloading or write. Unfortunately EVERY application isn't as "cooperative". -- Chris Parson via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!382!54!Chris.Parson INET: Chris.Parson@f54.n382.z1.FIDONET.ORG
ewm@mdavcr.UUCP (Eric W. Mitchell) (08/25/90)
In article <44150@apple.Apple.COM> daveo@Apple.COM (David M. O'Rourke) writes: > There are several example of multitasking system that aren't pre-emptive. >Lots of early computer OS's did the context switch off of some/all system >calls or other non-preemptive mech. I've yet to find an OS book that doesn't >mention co-operative multi-tasking as a scheduling mech. Agreed. You are on the nose with this one. > Multi-tasking _STRICTLY_ defined is the running of more than one process >at a time. Well to do that you need a CPU for each process. So any single >CPU system is not a multi-tasking system. Or when ever you get n+1 processes >going on an n-processor system then you no longer have a multi-tasking >system. Ummm, not quite. I think you are confusing *multi-tasking* with *multi-processing*. A _LOOSE_ definition of a *multi-tasking* system is that it has multiple processes *active* at the same time, with each making progress toward completion. A *multi-processing* system is one that has multiple processors executing code simultaneously. Note that a multi-processing system is not necessarily multi-tasking. The system may be designed so that that all processors execute code from a single program - as with a single-tasking *parallel processing* system. On the other hand, not all multi-processing systems are parrallel processing. A multi-processing system does not necessarily execute sections of the same program on different processors at the same time, whereas a parallel processing system does. * Whew!!! * >Therefore multi-finder is a multi-tasking extension of the Macintosh OS. Just >because the scheduling method doesn't do it the way most bigger OS's do it >doesn't remove the ability. > > There is more than one way to multi-task a system, and there will always be >debate regarding which way is best. Bravo. >daveo@apple.com David M. O'Rourke Eric ============================================================================= "I love to travel. You meet the most interesting people." - Attila T. Hun
JS05STAF@MIAMIU.BITNET (Joe Simpson) (08/29/90)
In article <13888@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) says: > >In article <2760@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman >Goodger) writes: >> >> Despite the -:)'s, I say there is no such thing as "True >> MultiTasking", you either have "pre-emptive" or "cooperative" >> MultiTasking. Take your pick... > Valentin replies: >Actually, you either have pre-emptive multitasking, or you have nothing. The above statement is a matter of perspective, but raises an issue that troubles me. The VM/CMS mainframe that I am using to compose this note has "pre-emptive multitasking". I presumable benefit from this in numerous ways, but if I want to run program B while waiting for program A to finish, I cannot do it. I can't even suspend program A to accomplish program B and then return to program A except in special circumstances. The Mac that is doing my terminal emulation currently has a work processor, terminal emulator, data base, and a second terminal emulator open. I can work whenever and wherever I want. Limited background processing and very fast context switching are available. My question: Can anyone describe the benifits I have on my Mac that are denied to me under VM/CMS is the simple and straightforward manner that Valentin discussed the hardware architecture issue?
rubinoff@linc.cis.upenn.edu (Robert Rubinoff) (08/29/90)
even though it's a "pre-emptive multitasking" system] This is sort of off the subject, but I feel obliged to mention that CMS is actually *not* a multitasking operating system. It's a single user operating system, so you can only run one program at a time. *VM* provides pre-emptive multitasking, but VM isn't really an operating system in the conventional sense; it's a virtual machine system. Thus many people can each be running CMS indepedently under VM at the same time, but each CMS virtual machine can only run one process at a time. If you want to be able to run multiple processes simultaneously, you have to run a multitasking OS under VM. This, of course, has nothing to do with the MAC; I just didn't want people to think that VM/CMS was a sample of what pre-emptive multitasking was like. Robert
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/29/90)
In <923@mdavcr.UUCP>, ewm@mdavcr.UUCP (Eric W. Mitchell) says: "preemptive multitasking slows down the system because it adds to the number of cycles required to perform a given operation." First of all, I'd like to say that I basically agree with Eric's viewpoint that the Mac *is* a multitasking system, albeit a non- preemptive one. However, even among preemptive systems, there're two broad strategies for divvying up the CPU time among tasks: time-slicing, and non-time-slicing. A time-slicing system forces a fair distribution of CPU time among a number of tasks with the same priority. It assigns a "quantum" of CPU time to each tasks, and does a reschedule immediately the current task exhausts its quantum. The suspended task gets a new quantum, but it goes to the end of the queue so it won't run again until every other task at the same priority level has had a chance. A non-time-slicing system only suspends the current task if a higher- priority one becomes computable. If such an event never happens, and the current task never goes into a voluntary wait state (such as waiting for an I/O operation to complete), it will continue running without interference from the scheduler. Time-slicing schemes evolved on timeshared multi-user systems, which need to protect themselves against compute-bound jobs hogging all the CPU and hurting the response time of other users. I consider their use inappropriate in a single-user environment. Consider: a PC is dedicated to serving the needs of one user. Whether it runs a preemptive or non-preemptive OS, all the tasks are still assumed to be *cooperating* in their service of a single user--you're not running a timesharing service on your desktop. Therefore, Eric's comment about preemptive multitasking *necessarily* involving extra overhead, I don't agree with. Provided you design the system specifically as an interactive single-user one, and not as a cut-down version of a multiuser one, the overhead can be kept very low indeed. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.