fischer@hermix.UUCP (Herm Fischer) (06/13/87)
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
martillo@bloom-beacon.UUCP (06/15/87)
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.
firth@sei.cmu.edu (Robert Firth) (06/16/87)
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.
martillo@bloom-beacon.UUCP (06/17/87)
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.
himel@mips.UUCP (Mark I. Himelstein) (06/17/87)
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
ivanovic%vaxr.DECnet@LLL-ICDC.ARPA ("VAXR::IVANOVIC") (06/17/87)
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
------martillo@athena.mit.edu (Yakim Martillo) (06/18/87)
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.
martillo@bloom-beacon.UUCP (06/19/87)
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.