comp.lang.ada
 help / color / mirror / Atom feed
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Subject: Re: Two questions
Date: 11 Apr 89 13:32:40 GMT	[thread overview]
Message-ID: <814@aber-cs.UUCP> (raw)

In article <124000035@inmet> callen@inmet writes:
    
    >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;
    
    This behavior is dependent upon the Ada runtime system implementation. MVS
    supports its own flavor of tasking, in which several tasks (threads of control)
    run in the same address space. On a machine with more than one physical
    processor (which is very common these days), several tasks in the same 
    address space can run simultaneously on different processors. If one of the
    tasks incurs a page fault, the other tasks do NOT wait.

Unfortunately I do not have a multiprocessor MVS system :->.

However on this subject, I cited OS/MVS and IMS preceisely because the
problem has been solved within them; MVS has one of the few multithreading
facilities (if that is the right word :->) around, and among others PL/1 uses
it etc...
    
    So what you want to look for is an implementation that allows you to 
    map Ada tasks to "true" MVS tasks. There are at least 2.

Let me add though that if I were selling an Ada compiler for MVS, I would
not boast that it does have real multithreading because it maps Ada tasks
onto MVS tasks; I would keep it a closely guarded secret. Why?

Easy is the answer: it is fairly obvious that Ada tasking was designed to
support a very fine grain of tasking, such as associating tasks with a
buffer pool, etc... Too bad that MVS tasks have truly stupendous overheads.

IBM are the first to admit this; in an old (early seventies) issue of their
Systems Journal (devoted to explaining the new VS2, as it was then called)
they discuss how it was decided that the MVS kernel internally would not use
MVS tasks, but rather lightweight tasks, precisely because TCBs are too
expensive to use in a multithread program like MVS itself.  Also, there must
be some good reason for which the major IBM databases or communication
subsystems or transaction processing systems don't use TCBs...

Too bad that those two vendors that you cite as allowing you to map Ada
tasks to "true" MVS tasks did not take the trouble of duplicating the IMS or
CICS internal schedulers, that do get page fault signals from the MVS
kernel. By the way, there is a facility to get page fault signals also in VM,
precisely because it is used to run multithreaded operating systems, and
these when run under it do use them.

On the other hand I must admit that using MVS tasks for Ada tasks, while
being quite inappropriate to the Ada style of tasking, does have the
advantage of being able to run them on multiple processors, which a simple
page fault handling in address space scheduler cannot do.

Unles sof course the in address space scheduler runs as multiple MVS tasks
(it, not the Ada tasks it manages). I don't really remember well, but some
recent version of IMS may do that.

Summing up, I thoroughy agree with other posters that Ada really requires
a lightweight thread implementation, and most current operating systems
do not qualify, either because they do not have threads or because they
are not lightweight. And, let me add, wasn't Ada supposed to run on
embedded systems where all tasks are lightweight, and there is no notion
of address spaces, not to speak of paging? :-] :-]
-- 
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-04-11 13:32 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1989-04-11 13:32 Piercarlo Grandi [this message]
1989-04-14 17:14 ` Two questions callen
  -- 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 ` Jon S Anthony
1996-11-08  0:00 ` Norman H. Cohen
1996-11-08  0:00 ` Robert I. Eachus
1996-05-01  0:00 Bernard Banner
1996-05-01  0:00 W. Wesley Groleau (Wes)
1996-05-01  0:00 Ed Seidewitz
1989-03-30 11:53 Piercarlo Grandi
1989-04-13  0:46 ` Paul Stachour
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