Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.lava.net!news.pixi.com!news.dod.hawaii.gov!paf-news.hqpacaf.af.mil!wrdiss1.robins.af.mil!gatech!news.mathworks.com!news.maxwell.syr.edu!hunter.premier.net!news1.best.com!nntp1.ba.best.com!usenet From: Bryan O'Sullivan <bos@serpentine.com> Newsgroups: comp.programming.threads,comp.unix.bsd.freebsd.misc Subject: Re: [??] pure kernel vs. dual concurrency implementations Date: 20 Feb 1997 07:44:31 -0800 Organization: Polymorphous Thaumaturgy Lines: 51 Sender: bos@organon Message-ID: <874tf7lbxc.fsf@serpentine.com> References: <330CE6A4.63B0@cet.co.jp> NNTP-Posting-Host: organon.serpentine.com X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: euryale.cc.adfa.oz.au comp.programming.threads:3257 comp.unix.bsd.freebsd.misc:35845 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> Pro strict kernel people say: m> * simpler model, less complicated scheduler Arguments from simplicity are oftentimes seductive and misleading, if what you are trying to achieve is good performance. 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. 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 My $.02. It's been a few years since I hacked on the internals of threads implementations, but I doubt anything has changed. <b -- Let us pray: What a Great System. bos@eng.sun.com Please Do Not Crash. bos@serpentine.com ^G^IP@P6 http://www.serpentine.com/~bos