Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!lhs.woodside.ca.us!dick
From: dick@lhs.woodside.ca.us (dick benster)
Newsgroups: comp.sys.next
Subject: Don't believe that SunOS Threads are equivalent to Mach's
Message-ID: <9105040321.AA00869@lhs.woodside.ca.us>
Date: 4 May 91 08:05:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 49
X-Unparsable-Date: Fri, 3 May 91 19:21:51 GMT-0800

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