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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.ada
Subject: Re: Two questions
Summary: tasking and page faults -- not an easy problem
Message-ID: <796@aber-cs.UUCP>
Date: 30 Mar 89 11:53:44 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
List-Id: <comp.lang.ada>

In article <9274@claris.com> peirce@claris.com (Michael Peirce) writes:
    >2. When a task has completed its execution, termination is delayed until all
    >   dependent tasks have terminated (9.4.6).  As a result, our program
    >   fills up all memory with completed tasks unable to terminate.  Why is
    >   this?  Can something be done about it (without altering task dependency)?
    >
    >
    >We have the impression that Ada was designed to deal with a small
    >number of large tasks, whereas we are trying to create a large number
    >of small tasks.  Is this true?  Does it matter?
    >
    
    The way we dealt with this problem was to reuse our tasks.  We had
    a situation where we wanted to dispatch a handler task for each incoming
    request from the network. In Vax Ada, the tasks weren't removed from
    memory until after the program exited the scope of the task declaration.

This is all nice and true, but of course hardly satisfactory. It essentially
defeats the idea of using dynamically created tasks. It is a style of
programming akin to that used in Concurrent Euclid or other languages
with only a static number of tasks configurable. The scheme though is
efficient and not too difficult to implement, and slightly more flexible.

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.

There are only two solutions, one fairly horrible, having a signal delivered
by the OS on a page fault to the in-address space scheduler, the second
and proper one is to have threads in the OS and associated Ada tasks with
the threads. Unfortunately the second one can be fairly expensive, many
systems have high overhead threads (e.g. OS/MVS).
-- 
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