Re: Two questions

Re: Two questions

[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)?
    >
    >
    >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

Re: Reusing Ada tasks

[William Thomas Wolfe,2847,]

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

Re: Reusing Ada tasks

[Bob Hathaway]

(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

Re: Two questions

[Paul Stachour]

In article <796@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

> ....
>There is another problem with Ada tasking, and it is well known to those

*** Stop. Let's get the problem in the right place.  It is NOT a 
*** problem with Ada, but with the OS that is running Ada.

>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).
***  Stop.  There is at least a third solution.  In ancient, 
***  multi-processor batch-systems that had time-sharing grafted on,
***  such as Honeywell's GCOS3, the time-sharing monitor handled its
***  own sub-threads, such as deciding when things were dispatchable
***  when they were not and when to swap a subtask and ...
***  And it let the OS do the dispatching.
***  Substitute/time-sharing-monitor/Ada RSL/ and it's not too different.
***  In the past, we had a multi-processing CPU that could do the
***  equivalent of dispatching two "ready" Ada tasks within a single OS
***  process.  Today, you tell me that OS/MVS, VAX/VMS, and such ilk
***  cannot even dispatch one such ready task.  ...Sigh
***  ...Ugh   Isn't "progress" wonderful.