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
Xref: utzoo comp.lang.ada:2226 comp.os.misc:846
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ncrlnk!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada,comp.os.misc
Subject: Re: Reusing Ada tasks
Message-ID: <4964@hubcap.clemson.edu>
Date: 31 Mar 89 02:22:22 GMT
References: <796@aber-cs.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Followup-To: comp.os.misc
Distribution: eunet,world
List-Id: <comp.lang.ada>

>From article <796@aber-cs.UUCP>, by pcg@aber-cs.UUCP (Piercarlo Grandi):
> 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)?
>     
>   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. [...]
% 
% 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. [...]
% 
% 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).


    Similar problems have plagued those who try to do multitasking in
    other languages as well.  The "task reuse" solution has been the
    most popular workaround.  But Ada tasking is not at fault: the 
    problem lies solely with the OPERATING SYSTEMS.  They use up
    large amounts of time modifying various data structures every time
    a process is created, and do this blindly without engaging in the
    task reuse optimization that application programmers are now having
    to program ON TOP OF the operating system.  

    So why aren't these operating systems being UPGRADED to 
    support current applications programming requirements???


    Bill Wolfe, wtwolfe@hubcap.clemson.edu