Path: utzoo!attcan!uunet!mcvax!hp4nl!phigate!philmds!leo From: leo@philmds.UUCP (Leo de Wit) Newsgroups: comp.sys.atari.st Subject: Re: Multitasking on the ST Message-ID: <1069@philmds.UUCP> Date: 12 Aug 89 14:26:05 GMT References: <8908021826.AA05333@ucbvax.Berkeley.EDU> <15627@watdragon.waterloo.edu> <1989Aug4.173233.8259@sj.ate.slb.com> <1067@philmds.UUCP> <1989Aug11.175942.6534@sj.ate.slb.com> Reply-To: leo@philmds.UUCP (Leo de Wit) Organization: Philips I&E DTS Eindhoven Lines: 86 In article <1989Aug11.175942.6534@sj.ate.slb.com> greg@sj.ate.slb.com (Greg Wageman) writes: |In article <1067@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: [some stuff left out] |> 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? Not quite, but to the same effect. What in fact happens, is that before the process enters the real GEMDOS function (the handling of Cconin or whatever) but after its context has been saved on its basepage and stack, the system will look at what process to continue with (of course this could just as well be the same process). Processes that are waiting for some state change like a character from the keyboard becoming available, or the printer being ready to receive further data, are marked that way and will only be selected if the state they're waiting for changes (the test for the changed state is just a simple index comparision in most cases). Calls that can be safely assumed to complete within a reasonable amount of time are not marked waiting (although one could perhaps win something by switching out a process that wants to write to disk when the disk is not yet available). When no waiting processes can be served (no state changes) the other processes are searched for the least served one (processes have a priority and a 'serviced' number). A few problem calls remain: Cconrs(), which reads an entire line from the keyboard. One can at best test for the first character being available, but the user could still take indefinitely to complete his line. Shells that do command line editing, history completion etc. generally won't have a problem, since they typically process their input character by character. A solution would be to rewrite Cconrs() to be re-entrant (no problem since I recently patched Cconrs() to handle a history mechanism, command line editing and file name completion). [] |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. Sure, but a) GEMDOS is not being re-entered and b) in a special way, GEMDOS IS re-entrant. After these stunning remarks, I'll have to make myself clear 8-): Consider a series of programs that call each other by a Pexec(), for instance a shell starts make, which starts a compiler, which ... Note that each of them only returns from their Pexec after the Pexec'ed program has finished. That program probably did a lot of GEMDOS calls ---> there you have your re-entrancy (in a special way). The whole trick is that, while one process cannot re-enter GEMDOS (it would at least trash registers left on the basepage for the restore of the previous call), multiple processes can very well all be in a GEMDOS call (they're not yet performing their function, only saved their state). |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. [story about semaphores, critical sections left out] But the time-slicing (implemented yesterday evening!) only takes effect when the program was in user mode. This guarantees you're not interrupting any progressing GEMDOS/(X)BIOS/GEM call. Small and beautiful. In fact, my semaphore is the supervisor bit in the program status word! |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... If there is a problem with this scheme, the problem can be reproduced in the current (unmodified) TOS, so it was already there. As for simultaneous updating, each GEMDOS call is completed before the next is done. No trashing. |Still, it sounds like fun to play with. It sure is!! B.T.W. does that sound like an alpha/beta tester :-) ? Cheers, Leo. P.S. The current version screamed for job control, signalling etc. so that's being implemented right now (together with some system calls like signal() and kill()).