PHIL@VMD.CSO.UIUC.EDU (Phil Howard) (07/28/90)
> From: 803 James Loser 654-1284 <JAL2@CLEMSON.BITNET> > > Use a scheduler to manage your task. When the interupt occurs, your FLIH > should save the state of who is getting stepped on and then service the > interrupt. When the interrupt is finished, control is given to the > scheduler (or dispatcher as some people prefer) which decides who still > needs to run and passes control to that process. When a process finishes, > control is again returned to the dispatcher which again decides who > who needs to run ..... This is the theoretically correct way to do it. But in the absense of a dispatcher, such as the case is with CMS, things get messy. In addition, just adding one is not that easy, since you need to make CMS jump to the dispatcher instead of just load a wait state PSW. If the application I mentioned has the constraint of running under CMS, the problems become very difficult. > From: Jim McIntosh <JIM@AUVM.AUVM.EDU> > > This is what operating systems do all the time. The solution is fairly > simple. The First Level Interupt Handler (FLIH) should receive control > disabled for interupts, that is the first byte of PSW NEW should be > zeros. Interupts which arrive while the PSW is masked off for interupts > are stacked until a PSW is loaded with indicate that it will accept > interupts. The FLIH can either restart the application (which accepts > interupts) which would be immediately interupted with your interupt, or > it can save PSW OLD and call a higher level interupt handler (which > generally run with interupts enabled). Good operating systems designed for multiple concurrent activity, of course, do just this kind of thing. CMS imposes different constraints. You can easily get into a "hang" situation where some CMS routine just loaded a wait state PSW instead of jumping to a dispatcher, which it knows nothing about. To make CMS fully multi-tasking requires redesigning CMS. I am interesting in finding the highest workable degree of overlap and concurrency that can be gotten into CMS without modifying CMS. But for other things, other systems do work better. RSCS and VTAM run under GCS, for instance, because they need the multitasking capabilities, among other things (such as near MVS-like compatibility). I've been designing a smaller multi-tasking OS for lesser needs, but with full multitasking and intertask communications using a server-client model for rendevous and symmetrical message channels. I'm developing this for the gap between CMS and GCS. ------------------------------------------------------------------------ I am presently working on a program that does overlapped tape I/O. Of course if there is nothing else going on inside the virtual machine, the problems are quite simple. But I have also written other sorts of background processes for CMS. For instance the first one I did was one to print files in a queue to a dialed in ascii terminal printer (the DECwriter was just becoming a popular printer then). While I no longer have need for that kind of thing, I certainly am envisioning others, such as NETWORKING application stuff. If we restrict interrupt processing to mask off all interrupts during such processing, then we always have completed contexts to deal with, and there is no ambiguity to knowing where to go to after interrupt completion. But unfortunately this rules out some kinds of background activity, such as spare-cycle number crunching. Under VM such things probably should be in a separate virtual machine anyway.
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (07/30/90)
On Fri, 27 Jul 90 18:09:00 CDT Phil Howard said: >Good operating systems designed for multiple concurrent activity, of course, >do just this kind of thing. CMS imposes different constraints. You can >easily get into a "hang" situation where some CMS routine just loaded a >wait state PSW instead of jumping to a dispatcher, which it knows nothing >about. To make CMS fully multi-tasking requires redesigning CMS. Phil: See sessions O714 and O715 ("Towards a Multitasking CMS - DIalog with IBM") to be presented at SHARE 75 in New Orleans in 2 weeks or so. Valdis Kletnieks Computer Systems Engineer Virginia Tech