dick@lhs.woodside.ca.us (dick benster) (05/04/91)
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. With Mach (including NeXT's version) on the other hand, each thread is separately blocked upon resource-wait without affecting other threads in the same task - they can still run. This is very desirable when you want to do real programming, accessing system resources from multiple threads (like all forms of I/O!). I've done threads work on Mach, and also on SunOS, but the limitations of SunOS threads preclude anything other than pure compute (non-resource dependent) threads for serious programming beyond a primary resource-handling thread. Since ALL interactions with the user involves I/O, Sun's implementation is quite limited when used for real-world problems, whereas Mach's solution is actually quite useable. Unfortunately, NeXT AppKit objects are not reentrantly written. Resultingly, a programmer may not use the full power of multiple Mach threads when using AppKit objects: only one thread may talk to the AppKit (or other synchronization code must be provided in multiple threads to prevent simultaneous references to an object). But when you step away from the AppKit world, like I am doing on my current multi-threaded data base/communications project, you have full access to Mach's true independent threads so long as you understand how to handle the inherent reentrancy/concurrent-references in the code that you might create. In summary, code written using Mach threads that depends on concurrency in multiple resource-accessing threads will not work on SunOS and other UNIXes with light-weight (really weenie-weight) threads... And it is not reasonable to produce Mach-like threads in SunOS without changing it into a Mach-like OS (how about Mach, Sun?)! Dick Benster La Honda Software
scott@nic.gac.edu (Scott Hess) (05/06/91)
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 <I still speak for nobody> "Simply press Control-right-Shift while click-dragging the mouse . . ." "I smoke the nose Lucifer . . . Banana, banana."
sritchie@cs.ubc.ca (Stuart Ritchie) (05/07/91)
In article <SCOTT.91May5180102@nic.gac.edu> scott@nic.gac.edu (Scott Hess) writes: >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 :-). What's being debated here is kernel supported vs. user level supported threads. I want to use user level supported threads for efficiency: trapping to operations in the kernel is at least 10 times more expensive than a procedure call. (Has anybody measured this in practice? I'm interested in hearing about it.) Kernel supported threads offer greater flexibility. Especially in a multiprocessor environment, where you might have threads of the same task scheduled on different processors. One may have to be more careful about synchronization (eg. critical sections) though. Another flexibility with kernel supported threads is IPC. Notice that in Mach, one thread can communicate with any other thread in the system. The kernel acts as a centralized nameserver for ports. Doing this at user level would probably be more expensive. ...Stuart
waltrip@capd.jhuapl.edu (05/08/91)
In article <1991May6.231923.19489@cs.ubc.ca>, sritchie@cs.ubc.ca (Stuart Ritchie) writes: > In article <SCOTT.91May5180102@nic.gac.edu> scott@nic.gac.edu (Scott Hess) writes: [...material deleted...] > > What's being debated here is kernel supported vs. user level > supported threads. > > I want to use user level supported threads > for efficiency: trapping to operations in the kernel is at least > 10 times more expensive than a procedure call. (Has anybody > measured this in practice? I'm interested in hearing about it.) Hmmm. I haven't but it's an interesting question alright. I would suspect that "user level" threads are implemented as coroutines and that longjmp/setjump are used when passing context from one thread to another voluntarily. When done via a user-written scheduler which depends on a timer routine, a kernel trap (the alarm system service) is performed anyway. So, if your thread(s) never blocks and you don't write a scheduler, I suspect "user level" threads might be somewhat more efficient. Unless I absolutely needed the efficiency, however, I'd stick with Mach threads where I could. c.f.waltrip Internet: <waltrip@capsrv.jhuapl.edu> Opinions expressed are my own.