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=1.1 required=5.0 tests=BAYES_20,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!bbn!inmet!ishmael!inmet!callen From: callen@inmet Newsgroups: comp.lang.ada Subject: Re: Two questions Message-ID: <124000035@inmet> Date: 3 Apr 89 14:44:00 GMT References: <674@uva.UUCP> Nf-ID: #R:uva.UUCP:-67400:inmet:124000035:000:1321 Nf-From: inmet!callen Apr 3 10:44:00 1989 List-Id: >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; >another Ada task is not redispatched, even if it could, because on virtually >all the Ada implementations I know of (notably the VMS one) the OS does not >know about Ada tasks at all. In other words, Ada tasking is not very good on >virtual memory systems if one wants to keep track of multiple external >events. The classic example is having a terminal monitor, with each terminal >served by its own task. This behavior is dependent upon the Ada runtime system implementation. MVS supports its own flavor of tasking, in which several tasks (threads of control) run in the same address space. 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. So what you want to look for is an implementation that allows you to map Ada tasks to "true" MVS tasks. There are at least 2. -- Jerry Callen Intermetrics, Inc. 733 Concord Ave. Cambridge, MA 02138 callen@inmet.inmet.com ...!uunet!inmet!callen