Microsoft OS/2 -- Ideal for Ada

Microsoft OS/2 -- Ideal for Ada

[Herm Fischer]

Microsoft OS/2 (the replacement for MS-DOS for 286 machines) seems to have
everything which Ada's tasking management needs, and Unix doesn't provide.

Unlike the balky fork concept of UNIX, OS/2 treats parallel executions
within a process as threads, which look at first glance as if they were
designed with Ada rendezvous in mind;  the threads can share the same
local data group, which is the opposite of UNIX fork semantics.

Given the apparent compatibility of Ada with OS/2, I'd like to see a discussion
of compiler vendor plans for supporting OS/2... 

(The only published public reference on OS/2 multiprocessing which I have
seen at newstands is in the May 1987 Microsoft Systems Journal, pg 29 ff.)

  Herm Fischer

Re: Microsoft OS/2 -- Ideal for Ada

[martillo]

In article <8706130340.AA00283@rand-unix.arpa> hermix!fischer@rand-unix.ARPA writes:
>Microsoft OS/2 (the replacement for MS-DOS for 286 machines) seems to have
>everything which Ada's tasking management needs, and Unix doesn't provide.

>Unlike the balky fork concept of UNIX, OS/2 treats parallel executions
>within a process as threads, which look at first glance as if they were
>designed with Ada rendezvous in mind;  the threads can share the same
>local data group, which is the opposite of UNIX fork semantics.

The correct question is whether the language implementer should
be mapping an Ada task into a Unix fork.  The Unix process is
an operating system entity which corresponds to a particular
model of computation  where user programs access a virtual machine in
isolation from all other programs and request services and request
services from the virtual machine via a generalized set of system
calls to the operating system.  Such a model makes logical i/o
and piping really trivial.  The Unix model is much more powerful
than the multics or vms model of computation.  

Now the Ada task is a programming entity which may have some use in
operating system develop and I would expect Ada tasking to compile to
processor specific tasking instructions such as are present on the
80386 or 80286 if such are present.  If such instructions are not
present, the compiler would have to simulate tasking instructions just
as a C compiler would simulate stack instructions on a machine which
had no specialized stack instructions.

Providing language level tasking by simulating non-existent tasking
instructions should be no more than a couple of days work for the
compiler writer.  The implied criticism of Unix in this article is
gratuitous and implies a lack of understanding.

>Given the apparent compatibility of Ada with OS/2, I'd like to see a discussion
>of compiler vendor plans for supporting OS/2... 

>(The only published public reference on OS/2 multiprocessing which I have
>seen at newstands is in the May 1987 Microsoft Systems Journal, pg 29 ff.)

>  Herm Fischer

I thought applications written in ADA were supposed to be portable.

Re: Microsoft OS/2 -- Ideal for Ada

[Robert Firth]

In article <928@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes:
>The correct question is whether the language implementer should
>be mapping an Ada task into a Unix fork...

>Providing language level tasking by simulating non-existent tasking
>instructions should be no more than a couple of days work for the
>compiler writer.  The implied criticism of Unix in this article is
>gratuitous and implies a lack of understanding.

I agree that it is inappropriate to map Ada tasks into Unix processes.
For one thing, the overhead is insupportable.

Unfortunately, the alternative doesn't work either.  Two serious
problems

(a) Unix does not provide asynchronous IO to a process.  If one Ada task
    does a read() from the terminal, the whole program blocks.  And you
    thought polling died out in the '60s?

(b) A large number of Unix system calls are not reentrant.  If one Ada
    task is suspended in a malloc(), chaos can ensue.

These problems (and others) cannot be fixed by the compiler writer.
All he can do is curse Unix (and rightly so, in my opinion) for a grossly
simplistic view of what "computation" is.

Re: Microsoft OS/2 -- Ideal for Ada

[martillo]

In article <1624@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE) writes:
>In article <928@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes:
>>The correct question is whether the language implementer should
>>be mapping an Ada task into a Unix fork...

>>Providing language level tasking by simulating non-existent tasking
>>instructions should be no more than a couple of days work for the
>>compiler writer.  The implied criticism of Unix in this article is
>>gratuitous and implies a lack of understanding.

>I agree that it is inappropriate to map Ada tasks into Unix processes.
>For one thing, the overhead is insupportable.

>Unfortunately, the alternative doesn't work either.  Two serious
>problems

>(a) Unix does not provide asynchronous IO to a process.  If one Ada task
>    does a read() from the terminal, the whole program blocks.  And you
>    thought polling died out in the '60s?

Actually, Berkeley Unix does provide asynchronous I/O.  If you use
substandard AT&T versions of Unix, you get what you deserve.

>(b) A large number of Unix system calls are not reentrant.  If one Ada
>    task is suspended in a malloc(), chaos can ensue.

This is a library problem not a language problem.  

>These problems (and others) cannot be fixed by the compiler writer.
>All he can do is curse Unix (and rightly so, in my opinion) for a grossly
>simplistic view of what "computation" is.

Since I myself have written multitasking packages for Unix which would
more than satisfy the needs of ada programming, I find this claim
rather dubious.  As for simplistic view of what computation is, I
would be curious how it is simplistic, the Unix designers set out to
define a true multi-user, multi-tasking, time-shared system with
logical I/O and a limited virtual machine capability.  As far as I
know Unix is one of the few systems which achieve this.  None of the
IBM systems qualify, nor does VMS nor does Multics nor does Multics --
at least from what I can tell from groveling through the source.

I would say that Unix achieves this precisely because of the powerful
simplicity of the operating system because the Unix developers made
the correct choice of fundamental operating system entites, the file
and the process and then constructed a rather sophisticated system on
top of these elements.

Unix loses in providing real-time capability and dynamic linking but
the developers limited their goals (a very good thing to do) and did
not intend to provide such capability although I do not think they
would be particularly hard to add if the developer has a proper
understanding of the Unix model of computation.

Re: Microsoft OS/2 -- Ideal for Ada

[Mark I. Himelstein]

In article <1624@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP writes:
...

>I agree that it is inappropriate to map Ada tasks into Unix processes.
>For one thing, the overhead is insupportable.

I agree too mainly due the horrible overhead of unix processes and the
shared nature of the ada memory model.


>Unfortunately, the alternative doesn't work either.  Two serious
>problems

I presume you mean multi-tasks within one unix process.



>(a) Unix does not provide asynchronous IO to a process.  If one Ada task
>    does a read() from the terminal, the whole program blocks.  And you
>    thought polling died out in the '60s?

BSD UNIX provides full asynchronous IO. This is done with ioctl's and fcntl's
and setting up a signal handler for SIGIO.


>(b) A large number of Unix system calls are not reentrant.  If one Ada
>    task is suspended in a malloc(), chaos can ensue.

Since Ada tasks would share memory, allocating from a shared heap like malloc
represents a critical region and other tasks should be blocked.

Mark I. Himelstein
decwrl!mips!himel

Re: Microsoft OS/2 -- Ideal for Ada

[Yakim Martillo]

Just out of curiosity, a lot of the posters have referred to the
tremendous overhead of unix processes.  While I grant that there is
overhead associated with Unix processes, the other two operating
systems I know best and despise a lot more (VMS and Multics) have far
more overhead associated with processes and generally really
discourage the user from spawning a new processes.  In both cases the
command interpreter loads the procedures which the use wants to invoke
and then directly calls the users routines.  Basically there is only
one process, the command interpreter.  If you like this sort of
environment you can always write a unix shell which will work this
way.  Of course pipelining processes becomes impossible.  With VMS and
Multics its fairly hard to disassociate a process from the terminal.
I think it may actually be impossible in the case of Mulics to
disassociate the process completely.  I find this limitation sort of
a pain.

RE: Microsoft OS/2 -- Ideal for Ada

["VAXR::IVANOVIC"]

I have a question for Yakim Martillo (bloom-beacon!martillo@husc6.harvard.edu).
It is NOT a religious question, but a technical one.  Yakim writes

    ... the Unix designers set out to define a true multi-user, multi-tasking,
    time-shared system with logical I/O and a limited virtual machine
    capability.  As far as I know Unix is one of the few systems which achieve
    this.  None of the IBM systems qualify, nor does VMS nor does Multics ...

My question is: What are the "fundamental operating system entities" and their
attributes that Unix provides that VMS, MVS and Multics do not provide?

								-- Vladimir
------

Re: Microsoft OS/2 -- Ideal for Ada

[martillo]

In classic unix, like I first used in 1975 the fundamental operating
system entities were files and processes.  If you understood
everything there was to understand about files and processes you
understood everything.  The tty was a file, the directory was a file,
and the pipe was an unnamed file.  The process was just about the only
entity that was not a file.  (Actually this is not quite true, there
were a few other objects like interrupt handlers which fit in neither
category) but in general there was nothing more which you really
needed to understand.

Multics was in some sense even simpler.  There is one fundamental
entity, the memory segment (though one could argue that the user's tty
was also a fundamental entity, but the importance of the user's tty is
perhaps more properly viewed as a result of the way Multics does I/O).
Unfortunately this seems to be a bad choice of fundamental entities
especially for me since I consider segmenting memory a stupid thing to
do  and based on a fundamental misconception that one wants to protect
regions of memory rather than operating system objects.

As for VMS and the various IBM operating systems, I am not sure what
the fundamental entities are and have the feeling that everything is
special cased which makes comprehension harder.