Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!stpeter.Eng.Sun.COM!cmcmanis From: cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: Multitasking is slower Keywords: games, multitasking Message-ID: <136736@sun.Eng.Sun.COM> Date: 6 Jun 90 06:43:23 GMT References: <279@smosjc.UUCP> <4039@darkstar.ucsc.edu> <1990Jun5.082227.29350@agate.berkeley.edu> Sender: news@sun.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 53 In article <1990Jun5.082227.29350@agate.berkeley.edu> (Joseph Chung) writes: >Hold on a minute. If I want to multitask, I must nicely ASK for resources >to be given, therefore incurring an extra overhead. However, if I take over >the machine, I TAKE whatever resources I want, bypassng the boss. Joseph, you have some fundamental misunderstandings here. Take a moment and think about this. It's true that you have to execute an additional 50 or 100 instructions _once_ to ask nicely for a resource for a game. However, once your game is up and running, you won't be asking anymore and won't be incurring any more "overhead" further, a couple of hundred, even a couple of thousand additional instructions on startup will occur faster than you can click the mouse or even notice that they have occured. Again, once you have the resources such as memory, full mouse/joystick ownership, disk drive ownership, etc. No one else will get those resources and you won't have to ask for them again. They are yours to abuse until you release them. >I have a question here: Does WB count as a process/task? Cuz if it does, >then exec must time-slice in order to share it with a running game. No >matter how small that slice of time is, it is still taken; otherwise, how >will WB know to respond when a mouse is clicked in its domain? Your question should have pointed out your blind spot here. Yes, the workbench is a process. However, when you own the mouse Workbench (and everyone else for that matter) will never get a mouse click unless your program decides to let it see one. A process that is idle like this (waiting on an event that your game won't allow to happen) takes NO time/overhead. The scheduler looks at the ready to run queue, and the highest priority/only thing on it will be your game. Everything else is waiting on a resource that you have correctly requested and now own. If you didn't correctly request them, the other tasks might not realize that you own them (most probably) and then they _would_ think they were ready to run and this would incur overhead. The presence of other tasks will have no more of an effect on your "time" than the existence of your data in memory has on slowing something down. (ie NO EFFECT) If you _want_ the trackdisk.device task to get some time so that it can load a file _for_ your game, you can release the disk drive and ask for a file. Then and only then will it use any cycles. The key here is that "multitasking friendly" doesn't mean you necessarily have to allow other tasks to run while you do, after all you really do "own" the machine and the OS will give it all to you if you ask nicely. To be friendly, you simply have to be willing to let the user ask your program to give back some resources to the other tasks, which your game can do for the user on a provisional basis. When the user is done and tells you game or whatever that they are done, the game can go out and take those resources back! -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"