Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!uunet!lotus!lotus.com!robertk From: robertk@lotatg.lotus.com (Robert Krajewski) Newsgroups: comp.sys.mac.system Subject: Re: Changes for preemptive multitasking (was Re: When will mac do...) Message-ID: Date: 7 May 91 21:22:38 GMT References: <1991May3.035637.4446@vax5.cit.cornell.edu> <811@newave.UUCP> <15931@helios.TAMU.EDU> Sender: news@lotus.com Distribution: comp Organization: /homes/robertk/.organization Lines: 55 In-Reply-To: rang@cs.wisc.edu's message of 7 May 91 05:56:48 GMT In article rang@cs.wisc.edu (Anton Rang) writes: For instance, take QuickDraw. Suppose that process A is busily doing a DrawPicture. What happens when process B is context switched in and tries to update its window which was moved earlier? I suspect there are parts of QuickDraw which expect various global variables and data structures to be in consistent states, and that you'd have a problem. There is a way to get around this. It would be the following rule: drawing is only done in a thread (flow of control) that is controlled by the Process Manager's (nee MultiFinder) event loop. Old programs would continue to work without changes. New programs would have to spawn off separate threads to actually compute things in an environment where they knew that preemptive scheduling was in effect. And, they would not be allowed to draw; an application would have to send events to itself, and handle the drawing in the round-robin thread. This is basically how OS/2-PM works. Even though it has true preemptive multitasking, Presentation Manager programs still have to obey the event-loop discipline, just as under Macintosh or Windows. (The PM event/message scheduler uses a round-robin approach so that it can serialize mouse and keyboard events.) The beneficial difference is that OS/2 apps can spawn threads (very cheap processes that live in the same address space as the spawner) that are decoupled from the PM thread discipline. Lengthy tasks should be performed in non-PM threads; in fact, PM will put up a dialog box if a task does not release control from a message handler in approximately a second. In OS/2 PM, drawing in the non-PM thread is discouraged, if not prohibited, even though the drawing environment is an argument to the graphics functions, instead of an implicit global as it is on the Mac. Non-PM threads cannot wait for or synchronously send messages to windows, but they can asynchronously send (post) messages to windows. OS/2 also offers more general forms of inter-thread (process) communications like semaphores and queues, if you don't want to use window messages. Some parts of the system which have been introduced for MultiFinder will help quite a bit when preemptive multitasking finally come... Programs which depend on global variables may have to be changed, though a lot of the functionality could be emulated by using the MMU to trap accesses to global variable addresses and emulate them (at some cost in speed). Programs which use the managers should work fine, since the *internals* can be changed to allow for pre-emptive multitasking without changing the interface. Exactly. The real problem with the Mac and ``real'' multitasking is that it's still possible for an application to know too much system globals and data structures -- these are things that Multifinder has to swap in and out when applications are switched. New facilities and interfaces to old facilities are much better about this, but I'm not enough of a Mac expert to say if you could build a cleaner, smaller multitasker assuming that *all* programs did in fact use all the latest/cleanest interfaces.