Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@nic.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Don't believe that SunOS Threads are equivalent to Mach's Message-ID: Date: 5 May 91 23:01:02 GMT Article-I.D.: nic.SCOTT.91May5180102 References: <9105040321.AA00869@lhs.woodside.ca.us> Organization: Gustavus Adolphus College Lines: 57 Nntp-Posting-Host: nic.gac.edu In-reply-to: dick@lhs.woodside.ca.us's message of 4 May 91 08:05:21 GMTLines: 57 In article <9105040321.AA00869@lhs.woodside.ca.us> dick@lhs.woodside.ca.us (dick benster) writes: Regarding porting NeXTstep to other platforms, n67786@cc.tut.fi (Tero Nieminen) writes: >>Mach threads (or lightweight processes as they are called >>elsewhere) can be implemented in other operating systems besides >>Mach. And in deed have been. For example SunOS has them. Whoa, let's be careful about thinking that Unix threads are equivalent to Mach threads just because they have the same name! There are threads, and then there are THREADS... SunOS threads are in no way equivalent to or as powerful as Mach threads. A tremendous limitation of SunOS threads is that if one thread is blocked by UNIX for a resource-wait, ALL threads of the same process are also blocked. In short, Sun has produced an impoverished implementation of threads. Before the flame-wars begin, I'd like to clarify that a bit. The Sun implementation of threads is done fairly high in the OS, I believe - it's somewhat akin to the many implementations of threads that I've seen in the public domain for anything from MSDOS PCs to BSD Unix machines. Basically, what happens is that the user process sets up seperate stacks and all, and a timer which is used to periodically switch between threads in the program - this is all handled in libraries compiled into the program, not in the OS. Meanwhile, Mach threads occur "under" Unix. Mach has threads in the first place, and layering Unix over Mach doesn't do much to that. When you use threads, you are using _Mach_ threads, rather than _Unix_ threads. If you wanted, you could even implement regular Unix threads on top of what's there (though I fail to see any reason why you'd want to). But, overall Mach threads are much more like seperate processes than Unix threads are (though not that close, I guess :-). To a certain extent, Mach threads are a superset of regular Unix threads. Most stuff should be port-able (by that I mean you could port it, not that it should compile first time - there's no standard out there for Unix thread libraries), but I'm sure there are programs which rely on the some of the limitations of using a thread library rather than OS threads for some sort of auto-synchronization. For instance, using the thread libraries out there, you should be able to fairly safely do calls to system routines like write(2) and read(2) without having to worry about them killing each other - more than likely, one thread physically couldn't call write() while another one was still in write(). With Mach threads, you could probably do it just fine - though I'm sure that the result probably wouldn't make a whole lot of sense . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Simply press Control-right-Shift while click-dragging the mouse . . ." "I smoke the nose Lucifer . . . Banana, banana."