Re: Ada and Unix--Blocked Tasks

[att!bu.edu!encore!pierson@ucbvax.Berkeley.EDU (Dan L. Pierson)]

Regarding Re: Ada and Unix--Blocked Tasks; mfeldman@june.cs.washington.edu (Mik
e Feldman) adds:

> What Paul might be getting at is the notion that an Ada compiler could
> (should) map each Ada task onto an OS-level process. I see no reason in
> principle why this could not be done; indeed, I think there may be vendors
> who are doing it in Unix (can anyone confirm this?). 

If you refer back to Jerry Callen's posting of a few days ago you'll
see that we do, indeed, do this.  At the minimum, it requires a Unix
extended with shared memory.  This leaves with traditional heavyweight
Unix processes and very slow task creation and switching times.  It
also causes some I/O problems because file descriptors cannot be
shared under normal Unix+shared memory.

The next step on the parallel road is to use a Unix with lightweight
parallel processes such as Mach threads (yes, I know that Mach isn't
really Unix but it doesn't matter) or our UMAXV's variable weight
processes.  Now thread creation is much faster and switching times are
also better.  The I/O problem is solved.  But rondevous (sp?) will
still be slower than a single process implementation and the max OS
thread/process limit will bite some programs.

So the next step is to multiplex Ada tasks as very lightwight entities
on lightweight threads.  I don't know of anyone who's released this
yet. 

All of the above works fine for people who want to use tasks for
parallel computation.  Unfortunately there is another group.  Folks
from a Cedar, Modula-2, etc. background like to use tasks as
programming abstractions to deal with such things as blocking IO.
Some of these people write programs that create *many* tasks; they
don't really want them to all try and run in parallel.  They would
really rather have Ada use a serial lightweight process mechanism like
Sun's.

Since Ada doesn't know about different types of tasks, what should a
poor vendor do?
--

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com