james@bigtex.cactus.org (James Van Artsdalen) (10/24/88)
> 07-Oct-88 10:06 "Maria J. Jones" NeXT Computer System > From: "Maria J. Jones" <mj11+@andrew.cmu.edu> > Rashid says Mach's unique features include the ability to execute > multiple activities or "threads" within a single program. I feel obligated to point out that Microsoft's OS/2 does this too. Their symbolic debugger, CodeView, also provides source-level capability for debugging threads. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
boykin@multimax.Encore.COM (Joe Boykin) (10/29/88)
>BTW, in Mach are threads a kernel feature like fork(), or just a >library call? Threads are implemented within the MACH kernel directly. When you do a unix fork() you really get a task with a single thread. That thread can then do a "thread_create()" to create more threads. There is a little bit of work to set up the new thread, such as suppling a new stack, initial PC, and then to set it going. The C-Threads library package, also provided with MACH, simplifies this. ---- Joe Boykin Encore Computer Corp Chairman, IEEE Computer Societies Technical Committee on Operating Systems UUCP: encore!boykin ARPA: boykin@encore.com
jsloan@wright.UUCP (John Sloan) (10/31/88)
desnoyer@Apple.COM (Peter Desnoyers): > In article <363@thor.wright.EDU> jsloan@wright.UUCP writes: >>Threads are neat. Not necessarily new, although MACH and OS/2 are the >>first "commercial" operating systems that I'm aware to feature them, >>but still neat. > > Most real-time kernels (commercial or not) use threads and call them > tasks. Ada, Simula, Modula 2, Smalltalk and probably other languages > provide "processes" which seem to fit the definition of a thread, but > as a language feature rather than an OS feature. > Yep, although in our own real-time kernel (there's no name for it... it's something we originally developed ten years ago and have used it widely), which we've ported across PDP/LSI-11s and 68000s, in assembler, C and Forth, we just call them "processes", since they're usually implemented on machines which do not provide such support (and hence there is no name conflict... I suppose on IBM mainframes you'd have to use some other term than "task" :-). Anyway, our own real-time "processes" are indeed threads, or processes that run in the same address space. On the implementations we have that run on top of Unix (currently on VAX/Ultrix, Sun-3/SunOS, and NCR Tower/System V engines), we use the term "lightweight processes" to differentiate between normal Unix processes. "Thread" would do just as well, I suppose. We use Ada and Modula-2 as well (and Concurrent C and Concurrent Prolog, etc.), but the lightweight processes in these are supported via language specific library calls, not by a general, consistent system interface. Copyright 1988 by John Sloan ...!ucsd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan Wright State University Research Center jsloan%wright.edu@relay.cs.net 3171 Research Blvd., Kettering, OH 45420 ...!osu-cis!wright!jsloan Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail. Copyright 1988 by John Sloan ...!ucsd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan Wright State University Research Center jsloan%wright.edu@relay.cs.net 3171 Research Blvd., Kettering, OH 45420 ...!osu-cis!wright!jsloan Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.