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,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!rjh
From: rjh@cs.purdue.EDU (Bob Hathaway)
Newsgroups: comp.lang.ada
Subject: Re: Reusing Ada tasks
Message-ID: <6378@medusa.cs.purdue.edu>
Date: 4 Apr 89 02:00:30 GMT
References: <796@aber-cs.UUCP> <4964@hubcap.clemson.edu>
Sender: news@cs.purdue.EDU
Distribution: eunet,world
Organization: Department of Computer Science, Purdue University
List-Id: <comp.lang.ada>

(Please excuse if this is sent twice, the first try didn't appear to succeed,
 the 'f' command apparently ignores all but the first newsgroup)

>% 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

Actually, they are.  BiiN has an Ada based operating system designed to
support tasking and operating systems based on the Mach kernel can also
provide full support for tasking (both systems also support distributed 
programming).  Since a cactus stack architecture provides the most natural
implementation of the Ada tasking model and virtual machine, a fault in a
lightweight process'es stack address space should not interfere with
execution of other tasks in the program and I don't see why page faults in
other regions of the address space should cause suspension of all related
threads of control either.  Anyway, since modern operating systems are 
designed to support threads (Ada tasks) within heavyweight processes
overhead should be minimal, especially when compared to the heavyweight
context switching and high process creation cost typical in a tool-based
environment.  When programming with the Unix interface, the two features
most notably lacking are support for lightweight processes and distributed 
programming.  These are usually left to specific vendors to provide leaving
compiler writers (or RTS implementors :-)) and distributed programmers with 
implementation specific programming.  Standards in these areas are 
*definitely* needed.  As frequently pointed out, since multi-processors
provide hardware support for concurrent programming and Ada is a concurrent
programming language, the popular operating systems seem to be the bottleneck
in the middle and updated operating system standards should provide the
answer.  I haven't looked at the POSIX standard yet but I'm hoping support
for lightweight processes and distributed programming is provided.

Bob Hathaway
rjh@purdue.edu