Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sjsca4!news From: greg@bilbo (Greg Wageman) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking on the ST Message-ID: <1989Aug11.175942.6534@sj.ate.slb.com> Date: 11 Aug 89 17:59:42 GMT References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com> <1067@philmds.UUCP> Reply-To: greg@sj.ate.slb.com (Greg Wageman) Organization: Schlumberger ATE, San Jose, CA Lines: 57 In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: > >The discussion about multitasking triggered my interest, so I decided >to try some things out. It appears that context switching is easy if >you do it at the moment of a GEMDOS call: all registers have been saved >on either the stack or the basepage, so in fact all you have to do is >check whether perhaps another process should continue (note the very >small overhead). To be able to have more than one process running >(detach a job), I made a small change to Pexec() so that a new process >can be started, but the parent process is not waiting for the child to >finish. If a process does a call that may involve some time, like >reading a character from the keyboard (Cconin(), Cnecin()), this >process only continues its call when there is a character available, so >it will not unnecessarily block other processes. Will you be trapping these interrupts so that you can potentially unblock tasks waiting on them? >Implementing this scheme took only about a rainy afternoon, so you >can't say the effort was that great. What I would like to add is a >time-slice mechanism for CPU bound processes (no GEMDOS calls for a >long time), based for instance on the VBL-interrupt. This is also easy: >if the CPU was in user mode when the interrupt occured (no pending >GEMDOS/(X)BIOS/GEM calls) and the current process has had its slice, >save registers a la GEMDOS and run another process. The blocked reason >that is kept with each process will tell the dispatcher how the >interrupted process must resume when it is ready to. I must admit the idea sounds like it has merit. However it's easy to try something like this when blissfully unaware of the pitfalls. The biggest one I see is that GEMDOS itself is not written to be re-entrant. You will have to be careful when you implement time-slicing that you do not suspend a process while it is in the midst of a GEMDOS call. (You can accomplish this by setting a "critical section" flag when the trap into GEMDOS occurs. When the time quantum expires, and the critical section flag is already set, you set still another flag which indicates that the task should block when it exits the critical section. When it exits, you clear the "critical section" flag and the "block on exit" flag, and suspend it). Otherwise, another process making a GEMDOS call which uses the same data locations will trash the results of the other task's partially-completed call. There are probably thousands of such potential problems. I don't even want to think about the potential for trashing the disk due to simultaneous updating... Still, it sounds like fun to play with. Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ Opinions expressed herein are solely the responsibility of the author.