comp.lang.ada
 help / color / mirror / Atom feed
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Subject: Re: Two questions
Date: 30 Mar 89 11:53:44 GMT	[thread overview]
Message-ID: <796@aber-cs.UUCP> (raw)

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

             reply	other threads:[~1989-03-30 11:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1989-03-30 11:53 Piercarlo Grandi [this message]
1989-03-31  2:22 ` Reusing Ada tasks William Thomas Wolfe,2847,
1989-04-04  2:00   ` Bob Hathaway
1989-04-13  0:46 ` Two questions Paul Stachour
  -- strict thread matches above, loose matches on Subject: below --
2002-07-04 22:25 Mark
2002-07-04 22:40 ` Jeffrey Creem
2001-03-12 10:59 Christoph Grein
2001-03-12 17:43 ` Stephen Leake
2001-03-09 18:27 chris.danx
2001-03-09 20:22 ` Mark Lundquist
2001-03-09 20:56 ` Randy Brukardt
2001-03-12 15:36 ` John English
2001-03-12 18:11   ` chris.danx
1996-11-09  0:00 tmoran
1996-11-11  0:00 ` Adam Beneschan
1996-11-13  0:00 ` Richard A. O'Keefe
1996-11-07  0:00 Ding-yuan Sheu
1996-11-07  0:00 ` Robert Dewar
1996-11-08  0:00 ` Robert I. Eachus
1996-11-08  0:00 ` Norman H. Cohen
1996-11-08  0:00 ` Jon S Anthony
1996-05-01  0:00 Bernard Banner
1996-05-01  0:00 W. Wesley Groleau (Wes)
1996-05-01  0:00 Ed Seidewitz
1989-04-11 13:32 Piercarlo Grandi
1989-04-14 17:14 ` callen
1989-03-29  9:16 HansM
1989-03-29 18:35 ` Michael Peirce
1989-03-31 13:10 ` stt
1989-03-31 18:59 ` Scott Simpson
1989-04-03 14:44 ` callen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox