Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mit-eddie!bbn!jr@bbn.com
From: jr@bbn.com (John Robinson)
Newsgroups: comp.sys.next
Subject: Re: NeXT & "threads"
Message-ID: <31813@bbn.COM>
Date: 3 Nov 88 07:09:47 GMT
References: <10736@reed.UUCP> <363@thor.wright.EDU> <17802@glacier.STANFORD.EDU>
Sender: news@bbn.COM
Reply-To: jr@bbn.com (John Robinson)
Organization: BBN Systems and Technologies Corporation, Cambridge MA
Lines: 29
In-reply-to: jbn@glacier.STANFORD.EDU (John B. Nagle)

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