From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!bbn!inmet!ishmael!inmet!callen From: callen@inmet Newsgroups: comp.lang.ada Subject: Re: Two questions Message-ID: <124000036@inmet> Date: 14 Apr 89 17:14:00 GMT References: <814@aber-cs.UUCP> Nf-ID: #R:aber-cs.UUCP:-81400:inmet:124000036:000:3912 Nf-From: inmet!callen Apr 14 13:14:00 1989 List-Id: >/* Written 9:32 am Apr 11, 1989 by pcg@aber-cs.UUCP in inmet:comp.lang.ada */ >/* ---------- "Re: Two questions" ---------- */ >In article <124000035@inmet> callen@inmet writes: > > >There is another problem with Ada tasking, and it is well known to those > >who know OS/MVS and IMS. When an Ada task takes a page fault, the entire > >address space is suspended waiting for resolution of the page fault; > > On a machine with more than one physical > processor (which is very common these days), several tasks in the same > address space can run simultaneously on different processors. If one of the > tasks incurs a page fault, the other tasks do NOT wait. > >Unfortunately I do not have a multiprocessor MVS system :->. It doesn't matter; regardless of how many processors there are in the system, MVS will allow other tasks to run while one is blocked for a page fault. > tasks, and that IMS and CICS don't use tasking for that reason> > >Too bad that those two vendors that you cite as allowing you to map Ada >tasks to "true" MVS tasks did not take the trouble of duplicating the IMS or >CICS internal schedulers, that do get page fault signals from the MVS >kernel. IMS and CICS do NOT get page fault signals from MVS. They DO use their own internal schedulers, but of very different flavors. IMS uses multiple address spaces to achieve concurrency (and an address space is a much "heavier" entity than a task within an address space); the idea is that the terminals and databases are owned by a "control region" and the code for each transaction runs in a "message processing region." The control region does use "true" MVS tasks within itself to achieve concurrency. CICS, on the other hand, uses a single address space AND a single task, and then does its own scheduling in that single task. THIS IS A BAD PERFORMANCE BOTTLENECK! The reason is precisely the one you described: a page fault stops the entire region. In recent years CICS has acquired a facility similar to the IMS message processing region, called MRO (Multiple Region Option), to help with this problem (and other) problems, and has also begun to use multitasking (for DB2 and VSAM file access). In order to use the "page fault" option of the ESPIE macro (the macro that sets up "trap" handlers) you must be "authorized." This means, in MVS, allowed to enter supervisor state. Should every Ada program any user writes to be allowed to enter supervisor state? >On the other hand I must admit that using MVS tasks for Ada tasks, while >being quite inappropriate to the Ada style of tasking, does have the >advantage of being able to run them on multiple processors, which a simple >page fault handling in address space scheduler cannot do. Precisely. Since multiprocessors are rapidly becoming the norm for IBM 370 architecture machines, it is foolish not to exploit them. I think that MVS tasks are QUITE appropriate for Ada tasking, if used judiciously. >Summing up, I thoroughy agree with other posters that Ada really requires >a lightweight thread implementation, and most current operating systems >do not qualify, either because they do not have threads or because they >are not lightweight. Right, but if "midweight" threads are what you've got, you use them. :-) >And, let me add, wasn't Ada supposed to run on >embedded systems where all tasks are lightweight, and there is no notion >of address spaces, not to speak of paging? :-] :-] Yeah, but the customer wants MVS, and the customer is always right. :-) >Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk >Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg >Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk -- Jerry Callen Intermetrics, Inc. ...!uunet!inmet!callen callen@inmet.inmet.com