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
tart@reed.UUCP (Stephanie Shelton) (10/25/88)
In article <9772@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >> 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. And then of course there's Concurrent C. Unix has had the ability to do this for a while. It's all a question of how you most effectively program it. -me -- ------------------------------------------------------------------------------- "I do not take drugs. I am drugs." -Salvador Dali (still alive, 9/27/88)
libes@cme-durer.ARPA (Don Libes) (10/26/88)
In article <10736@reed.UUCP> tart@reed.UUCP (Stephanie Shelton) writes: >In article <9772@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >>> 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. >And then of course there's Concurrent C. Unix has had the ability to do this >for a while. It's all a question of how you most effectively program it. In conversation, Rashid pointed out that if you have a multiprocessor architecture, MACH threads can really run in parallel (as opposed to time-slicing on a single CPU). None of UNIX, OS/2, threads support this. Must be hell debugging. Don Libes libes@cme.nbs.gov ...!uunet!cme-durer!libes
sean@ms.uky.edu (Sean Casey) (10/27/88)
In article <683@muffin.cme-durer.ARPA> libes@cme.nbs.gov (Don Libes) writes: >In conversation, Rashid pointed out that if you have a multiprocessor >architecture, MACH threads can really run in parallel (as opposed to >time-slicing on a single CPU). None of UNIX, OS/2, threads support this. There's Dynix, Sequent's operating system. It a pretty decent multiprocessor operating system. 4.3 and SysV compatable. But then again, it's not called Unix either. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet *** The Hacker from Spaaaaaaaaace. {backbone|rutgers|uunet}!ukma!sean *** U of K, Lexington Kentucky, USA ..where Christian movies are censored. *** ``The World... she's a flat! She's a round! Flat! Round! Flat! Round!''
jsloan@wright.UUCP (John Sloan) (10/27/88)
Threads, or sometimes "light weight processes", have been around in various operating systems for a long time. The general accepted definitions for current technology is that processes run in separate address spaces, while threads (or LWPs) run in the same address space as the parent. There are an awful lot of real-world problems, as Unix programmers well know, where elegant solutions lend themselves to a multiple process approach. Unfortunately on most operating systems, multitasking (where task==process; multiprocessing might be a better term, but usually means to have multiple CPUs) has too much overhead. Not that that stops us C programmers, although in fairness Unix perhaps has less per-process overhead than other operating systems. And you can't beat the simplicity of the system call to create a new process: a single parameterless function. People have been creating light weight process kernels on top of production operating systems for a long time, or implementing the same kernels on small non-multitasking systems (like PCs and older LSI-11s). 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. 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.
jdn@mas1.UUCP (Jeff Nisewanger) (10/28/88)
In article <683@muffin.cme-durer.ARPA> libes@cme.nbs.gov (Don Libes) writes: >In article <10736@reed.UUCP> tart@reed.UUCP (Stephanie Shelton) writes: >>In article <9772@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >>>> 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. > >>And then of course there's Concurrent C. Unix has had the ability to do this >>for a while. It's all a question of how you most effectively program it. > >In conversation, Rashid pointed out that if you have a multiprocessor >architecture, MACH threads can really run in parallel (as opposed to >time-slicing on a single CPU). None of UNIX, OS/2, threads support this. > >Must be hell debugging. > >Don Libes libes@cme.nbs.gov ...!uunet!cme-durer!libes Newsgroups: comp.sys.next Subject: Re: NeXT & "threads" Summary: Expires: References: <592245952.ralphw@IUS3.IUS.CS.CMU.EDU> <9772@bigtex.cactus.org> <10736@reed.UUCP> <683@muffin.cme-durer.ARPA> Sender: Reply-To: jdn@mas1.UUCP (Jeff Nisewanger) Followup-To: Distribution: Organization: Measurex Automation Systems, Cupertino, CA Keywords: >>>> 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. >In conversation, Rashid pointed out that if you have a multiprocessor >architecture, MACH threads can really run in parallel (as opposed to >time-slicing on a single CPU). None of UNIX, OS/2, threads support this. >Don Libes libes@cme.nbs.gov ...!uunet!cme-durer!libes OS/2 threads are supported directly by the operating system and if/when the right hardware becomes available its threads will be distributed among the processors. Jeff Nisewanger .....apple!mas1!jdn
rick@seismo.CSS.GOV (Rick Adams) (10/28/88)
In article <10448@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: > There's Dynix, Sequent's operating system. It a pretty decent multiprocessor > operating system. 4.3 and SysV compatable. But then again, it's not called > Unix either. While the Sequent is a decent machine it is only 4.3 compatible is someones wildest fantasies. It IS 4.2bsd comptible, including many of the 4.2bsd bugs. --rick
louie@trantor.umd.edu (Louis A. Mamakos) (10/28/88)
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. The operating system for the UNIVAC/Sperry/Unisys 1100 series of mainframes has support `activities' (light weight processes) and multi-processor systems since the early 1970's. The OS also did a good job supporting batch, interactive and realtime applications. Too bad the file system is totally brain damaged. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
johnl@ima.ima.isc.com (John R. Levine) (10/29/88)
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. OS/360 MVT had threads in the mid-1960s (whether they worked then is a separate issue, but they were certainly there) and they weren't particularly new then. I think at this point they can be considered to be a time-proven operating system feature, like, perhaps, virtual memory. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { bbn | think | decvax | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
okrieg@eecg.toronto.edu ("Orran Y. Krieger") (10/29/88)
I believe that the current version of MACH on Next does not support
multiple processors. However even when it will, each NEXT CPU board has
its own local memory etc... Does anyone know if when multiple processor
boards can be put in will they have a global physical address space
(i.e. processor A can address processor B`s memory). Hmmm no cache so
I guess that there would be no consistency problem. However MACH assumes
uniform access time to memory from all processors. In a recent talk by
someone from BBN we were told that they had real problems getting around
this assumption. I came away with the belief that they decided that threads
were not worth supporting except on a single processor. Will this not
also be the case with Next?
--
Orran Krieger
University of Toronto -- Toronto, Canada
UUCP: {decvax,ihnp4,linus,utzoo,uw-beaver}!utcsri!godzilla.ele!okriegbc@halley.UUCP (Bill Crews) (11/01/88)
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. CICS has been around for a decade or so. Its tasks are threads. Data General once had an in-memory real-time OS called RTOS, which supported nothing but threads. When they made it disk-based (RDOS), each of the foreground and background partitions could multitask as RTOS previously did. Then they arrived at AOS and later AOS/VS. In these, each of the many OS processes can multitask. The threads are called tasks. I'm sure there are many other examples, and older ones, too. Threads are not at all new. Formal treatment of threads in OS theory seems to be somewhat newer than the implementations to date, oddly enough, n'est ce pas? -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc
jkrueger@daitc.daitc.mil (Jonathan Krueger) (11/02/88)
In article <401@halley.UUCP>, bc@halley (Bill Crews) writes: >CICS has been around for a decade or so. Its tasks are threads. I'm sure someone will correct me if I'm wrong here: CICS tasks can only share address space, they cannot get a separate address space even if protection needed and overhead justified. Unix processes can only use a separate address space, they cannot share address space even if well behaved, trusted, and frequently executed. Mach process constructs offer the union of CICS and UNIX possibilities, so you can use the right tool for the job. -- Jon Jonathan Krueger Netnews license #12019831 (expires June, 1989) If you see this poster being operated in an unsafe manner, call ...uunet!daitc!jkrueger jkrueger@daitc.arpa (703) 998-4777
bds@lzaz.ATT.COM (B.SZABLAK) (11/02/88)
In article <222@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: > I'm sure someone will correct me if I'm wrong here: CICS tasks can > only share address space, they cannot get a separate address space > even if protection needed and overhead justified. Unix processes can > only use a separate address space, they cannot share address space > even if well behaved, trusted, and frequently executed. Using fork() you get processes that share text space, and using shared memory operations (shmop() et. al.) selected portions of data space may be shared between processes.
jr@bbn.com (John Robinson) (11/03/88)
In article <17802@glacier.STANFORD.EDU>, jbn@glacier (John B. Nagle) writes: >This implies a degree of concurrency within the operating >system foreign to UNIX. For example, it's possible to close a file while >an I/O operation on it is in progress. UNIX's rather simplistic approach to >locking is insufficient for such an environment. Solutions are known, though. > I haven't seen the MACH internals, but I expect that the attention >paid to locking far exceeds that seen in UNIX. Indeed this is required. Not all there yet though, as the early versions still serialized the file i/o (ouch!). I recall a talk by Sequent that said that they had to rewrite something like 75% of BSD Unix to get it reentrant. In the process they removed a number of bugs (race conditions) which no one had happened to encounter (probably) due to typical timing on serial machines. In other words, this leads to much better OS software when you're done. Another thing Mach is doing which will help is reversing the trend dating back through BSD to put more and more into the kernel, and putting the split-out functions into normal processes. A housecleaning that should give Mach a longer useful lifetime plus more portability. This sounds expensive, but it is more than compensated by other improvements that result in Mach outperforming 4.3bsd on comparable (serial) machines, just in case anyone was worried. -- /jr jr@bbn.com or bbn!jr
bzs@encore.com (Barry Shein) (11/11/88)
>I believe that the current version of MACH on Next does not support >multiple processors. However even when it will, each NEXT CPU board has >its own local memory etc... Does anyone know if when multiple processor >boards can be put in will they have a global physical address space >(i.e. processor A can address processor B`s memory). Hmmm no cache so >I guess that there would be no consistency problem. However MACH assumes >uniform access time to memory from all processors. In a recent talk by >someone from BBN we were told that they had real problems getting around >this assumption. I came away with the belief that they decided that threads >were not worth supporting except on a single processor. Will this not >also be the case with Next? At the risk of bordering on commercialism (but actually just trying to provide an existence proof): Encore delivers Mach on its multiprocessors with threads fully supported across multiple processors. A lot of the parallelism work is done here although I'm not sure how much in that particular arena, I could check easily enough (I could read the sources!) It all depends on the details of the parallel architecture you are trying to support, that's a complicated issue. What works well for one may indeed be difficult on another and BBN is obviously trying to provide the best tools for their architecture. -Barry Shein, ||Encore||
wald-david@CS.YALE.EDU (david wald) (11/15/88)
In article <8760@spl1.UUCP> bc@halley.UUCP (Bill Crews) writes: >Threads are not at all new. Formal treatment of threads in OS theory >seems to be somewhat newer than the implementations to date, oddly >enough, n'est ce pas? Is this odd? I thought OS theory usually followed practice. ============================================================================ David Wald wald-david@yale.UUCP waldave@yalevm.bitnet ============================================================================