Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.mel.connect.com.au!news.mel.aone.net.au!grumpy.fl.net.au!news.webspan.net!newsfeeds.sol.net!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!newsxfer3.itd.umich.edu!newsxfer.itd.umich.edu!uunet!in3.uu.net!192.244.176.52!news.iij.ad.jp!news.CET.CO.JP!hydra.parkplace.ne.jp!michaelh From: Michael Hancock <michaelh@hydra.parkplace.ne.jp> Newsgroups: comp.programming.threads,comp.unix.bsd.freebsd.misc Subject: Re: [??] pure kernel vs. dual concurrency implementations Date: Fri, 21 Feb 1997 18:40:03 +0000 Organization: CATENA Enterprise Technologies Lines: 50 Message-ID: <Pine.BSF.3.95.970221180902.15657A-100000@hydra.parkplace.ne.jp> References: <330CE6A4.63B0@cet.co.jp> <874tf7lbxc.fsf@serpentine.com> NNTP-Posting-Host: hydra.parkplace.ne.jp Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <874tf7lbxc.fsf@serpentine.com> Xref: euryale.cc.adfa.oz.au comp.programming.threads:3272 comp.unix.bsd.freebsd.misc:35920 On 20 Feb 1997, Bryan O'Sullivan wrote: > m> Assuming a well designed strict kernel implementation and a well > m> designed dual concurrent model, say like Digital UNIX, both using > m> FreeBSD as a starting point, which is the way to go? > > I would expect two-level scheduling to give better thread context > switch times than a kernel-only implementation. [..] > m> In DEC's model it doesn't look like you need to worry about > m> converting blocking calls to non-blocking calls as in other > m> userland implementations. > > Two-level implementations are not similar to pure user-level > implementations, so your "... as in other ..." is misleading. Ok. Just to confirm, there are dual concurrency implementations that do the non-blocking thing, right? Anyway, it seems like a lot of grunt work to implement. > m> Instead they have some kind of upcall mechanism that supplies a new > m> kernel execution context to the userland process so that another > m> thread can be scheduled if the current one is blocked. > > m> Pure kernel proponents say that in the time all that was done a new > m> kernel thread could have been switched in. > > This is probably true. There are a few points to note, though: > > - Scheduler activations, or upcalls, only need to be performed when > your process is not running at a "reasonable" concurrency level > > - This means that for most programs, you only have paths through the > kernel occasionally, versus at every context switch for pure kernel > threads > > - The overhead of deciding when to make an upcall and performing the > upcall itself should not be significantly greater than that of > switching kernel-supprted threads Are there certain applications better handled by pure kernel threads and others better handled by a dual concurrency implementation? Regards, Mike Hancock