Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!jarthur!uunet!microsoft!edwardj From: edwardj@microsoft.UUCP (Edward JUNG) Newsgroups: comp.arch Subject: Re: Macintosh OS Message-ID: <54992@microsoft.UUCP> Date: 1 Jun 90 00:21:35 GMT References: <402@newave.UUCP> <3300131@m.cs.uiuc.edu> <5031@quanta.eng.ohio-state.edu> <1990May28.083518.26003@laguna.ccsf.caltech.edu> Reply-To: edwardj@microsoft.UUCP (Edward JUNG) Organization: Microsoft Corp., Redmond WA Lines: 41 In article <1990May28.083518.26003@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >Cooperative multitasking is excellent for single user environments because the >"foreground" process can always offer the best response time. Scheduling is not >much of an issue, but there are extra burdens on the programmer and that is the >real problem that Apple ought to deal with. Cooperative multitasking does not guarantee best response time for the foreground process. Actually, it offers the possibility of exceptional and uncontrolled degradation of the foreground process. If a foreground process IS a foreground process (that implies that there are one or more background processes), then any time it gives a timeslice away, it may not get control back for a long time. Indeed, a pre-emptive multitasking system that was optimized toward foreground tasks can give BETTER response to the user than cooperative multitasking because the scheduler could give guaranteed responses to the foreground process (note the wonderfully helpful fact that there is only ONE foreground process, making the real-time scheduling problem rather simpler). Now it may be true that very few systems give real-time overrides or guaranteed response times to foreground tasks (though there are some systems that do!), but that is an issue largely orthogonal to that of cooperative vs. preemptive multitasking. The thing that pre-emptive multitasking does is give guarantees against poor code. The Macintosh (and Windows) have gained alot of mileage with cooperative multitasking (note that this does not apply to ALL Windows apps) solely because their apps give up time relatively frequently. Even so, any single misbehaved application in the background can utterly destroy the preformance of a correctly written application in the foreground. Now whether the guarantees of pre-emptive multitasking are correctly architected or are even required (given the quality of applications) is another area of debate. >Todd Whitesel >toddpw @ tybalt.caltech.edu Edward Jung Systems Architecture Microsoft Corp.