Re: Two questions

[callen@inmet]

>/* 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.

> <Comments about "true" MVS tasking being too expensive for Ada
>  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