martin@felix.UUCP (Martin McKendry) (11/09/89)
In article <89307.092707GIAMPAL@AUVM.BITNET> GIAMPAL@AUVM.BITNET writes: >You said that OS/2 is small for its power. I'm naive about what it offers at >a technical level, so I'd like to know what it's power is. All that the >press about it has mentioned is that it multi-tasks, and that is NO reason >to require such a large amount of memory. I really would like to hear >a technical discussion of what it offers. Nothing I have read (which isn't >much) has mentioned if it has virtual memory or protected memory, etc... > What about the IPC support that it has? Is it easy to use? What about >spawning child processes, etc... You need to read, or at least peruse "Inside OS/2", by Gordon Letwin, Microsoft Press, 1988, ISBN 1-55615-117-9, $19.95 at a store year you. I got mine at B. Dalton. OS/2 has almost everything that Unix System V Release 4 has, and then a few things. It is very extensive, and in general contains the most current version of whatever feature you want. For example, it has more support for process management -- lightweight processes & semaphores etc -- than most versions of Unix. Discussions about OS/2 tend to be a little religious, and tend to be based on previous experience with MS-DOS. OS/2 is a real operating system, just as current versions of Unix are. Its 'power' is just what you would expect -- no more or less. However, when contrasted with MS-DOS, it looks very powerful, and this tends to dominate discussions. In fact, OS/2 has so many features derived from the Unix world, that you have to wonder if royalty avoidance didn't play a part in the decision to build a new operating system. (Not that there is anything wrong with learning from Unix: any competant engineer studies the current state of the art before building something new). -- Martin S. McKendry; FileNet Corp; {hplabs,oliveb,spsd,zardoz}!felix!martin Strictly my opinion; all of it
alex@mks.com (Alex White) (11/15/89)
In article <124944@felix.UUCP> martin@felix.UUCP (Martin McKendry) writes: >OS/2 has almost everything that Unix System V Release 4 has, and then a >few things. It is very extensive, and in general contains the most ``Almost everything''??? The most important feature of ALL Unix systems is lacking in OS/2. OS/2 has multi-TASKING. OS/2 DOES NOT HAVE multi-USER support. In case the distinction escapes people, this means file protection, and process protection (i.e. under OS/2 you can send whatever signal you want to whatever process you want). In the same amount of memory that will support OS/2 with one user, you can support say 386/ix, with perhaps 8 users. (which isn't quite a fair comparison, because the 1 user gets a fancy graphics interface which the 8 users don't.) >current version of whatever feature you want. For example, it has more >support for process management -- lightweight processes & semaphores >etc -- than most versions of Unix. Yes, but the question becomes, just how many different applications use these things? A lot of things have been done under Unix boxes without threads. Unix has the concept of fork, and people program to use that construct. OS/2 has the concept of threads, and people program to use that construct. The end result, is frequently the same. I would also point out, that if its a good idea, then Unix will implement it very quickly and simply. Given unix source, I could put some form of threads in place within a week.
hellerst@husc7.UUCP (Joe Hellerstein,,,) (11/17/89)
From article <1989Nov15.155723.4430@mks.com>, by alex@mks.com (Alex White): > > Yes, but the question becomes, just how many different applications use > these things? A lot of things have been done under Unix boxes without > threads. Unix has the concept of fork, and people program to use that > construct. OS/2 has the concept of threads, and people program to use that > construct. The end result, is frequently the same. > > I would also point out, that if its a good idea, then Unix will implement > it very quickly and simply. Given unix source, I could put some form > of threads in place within a week. Note that "UNIX" already has threads -- in MACH, which runs a BSD-like system, with extensions. And it seems likely that MACH will slowly replace older flavors of UNIX over the next ten years or so. The big advantage to threads over fork is that fork is an expensive system call -- you have to allocate all the resources (virtual memory space, running context, etc.) for every fork call you make, and then these separate processes can't, for instance, share memory or do very clean communication. Threads cost very little to fire off, and therefore you can afford to use lots of them -- this is very very useful when you would like to do many things "at once". Your argument about fork is very restrictive. New technology is always used in copycat ways for a while, but I submit that threads are significantly more powerful than fork, and that many applications will be able to make use of them to great advantage. Joe Hellerstein
golding@saturn.ucsc.edu (Richard A. Golding) (11/19/89)
In article <1989Nov15.155723.4430@mks.com>, alex@mks.com (Alex White) writes: > >current version of whatever feature you want. For example, it has more > >support for process management -- lightweight processes & semaphores > >etc -- than most versions of Unix. > ... > I would also point out, that if its a good idea, then Unix will implement > it very quickly and simply. Given unix source, I could put some form > of threads in place within a week. Very few Unix systems *don't* have threads available these days. The difference is that threads have been implemented as libraries, rather than as kernel-level entities. Sun OS4 has liblwp (light-weight processes) as a standard feature; Brown Threads and others exist as publicly available implementations... Of course not all library-based implementations are preemptive, but many are. Of course, for Unix you can get specialised toolkits (e.g. ISIS), which you certainly can't for OS/2. -richard (golding@saturn.ucsc.edu) ----------- Richard A. Golding, Crucible and UC Santa Cruz CIS Board Internet: golding@saturn.ucsc.edu Work: {uunet | ucscc.ucsc.edu}!cruc!golding
alex@mks.com (Alex White) (11/21/89)
In article <3189@husc6.harvard.edu> hellerst@husc7.UUCP writes: >Your argument about fork is very restrictive. New technology is always >used in copycat ways for a while, but I submit that threads are significantly >more powerful than fork, and that many applications will be able to make >use of them to great advantage. HUH? New Technology? Threads aren't much different from the concept of multiple tasks running in the same address space, sharing one TIOT. Have you heard of OS/360 running MVT? Now, I'm not quite sure just how lightweight tasks were back then, but the concept was quite the same.
madd@world.std.com (jim frost) (11/23/89)
alex@mks.com (Alex White) writes: >In article <3189@husc6.harvard.edu> hellerst@husc7.UUCP writes: >>Your argument about fork is very restrictive. New technology is always >>used in copycat ways for a while, but I submit that threads are significantly >>more powerful than fork, and that many applications will be able to make >>use of them to great advantage. >HUH? >New Technology? Yea, he's right. Threading has been around a long time, you know; many dedicated applications do it. Personally I recognize four execution primitives: fork(), thread(), exec(), and spawn(). Fork() duplicates a process exactly. Thread() duplicates a process context and stack (please, no flames about copy-on-write and other techniques, I'm trying to get at the essence, not the implementation). Exec() overwrites a process with another, and spawn() creates a new process altogether. These primitives go by a lot of different names, but almost everybody recognizes that they're pretty much it for the primitives. UNIX was one of the first operating systems that bothered with either fork() or thread(), and versions of UNIX have had everything but spawn for awhile (hey, it's possible to spawn by fork then exec so why have it?). Just not the major versions. Most other operating systems only had spawn() and *maybe* exec(). I grew up with the "most other" type operating systems and it took awhile to learn that fork() was a powerful construct. Thread() is even more powerful, but not a hell of a leap from the techniques you use with fork(), especially when you have shared memory. Most operating systems books have discussed these primitives for years (under various names), long before Mach and OS/2 and other threading operating systems were around. It's primitive stuff, nothing new here. The only thing new about it is that people are actually starting to put it in the operating system and not in the application. A natural step. Hell, it took 'em long enough to realize that maybe the operating system should take care of efficient use of the hardware -- MVS people still refuse to believe that -- so I'm not surprised. Careful about what you call "new technology." Most of the time it's been out there but you just haven't seen it. There is absolutely nothing I've seen in OS/2 that wasn't covered in more detail elsewhere (you might want to go find some information on MULTICS; you'll learn something). Happy hacking, jim frost software tool & die madd@std.com