Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!lucy.swin.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news.mathworks.com!uunet!in1.uu.net!204.191.213.61!ott.istar!istar.net!gateway.qnx.com!not-for-mail From: doug@qnx.com (Doug Santry) Newsgroups: comp.programming.threads,comp.unix.bsd.freebsd.misc Subject: Re: [??] pure kernel vs. dual concurrency implementations Date: 24 Feb 1997 08:58:13 -0500 Organization: QNX Software Systems Lines: 61 Message-ID: <5es6pl$25a@qnx.com> References: <330CE6A4.63B0@cet.co.jp> <874tf7lbxc.fsf@serpentine.com> <Pine.BSF.3.95.970221180902.15657A-100000@hydra.parkplace.ne.jp> NNTP-Posting-Host: qnx.com Xref: euryale.cc.adfa.oz.au comp.programming.threads:3290 comp.unix.bsd.freebsd.misc:36042 In article <Pine.BSF.3.95.970221180902.15657A-100000@hydra.parkplace.ne.jp>, Michael Hancock <michaelh@hydra.parkplace.ne.jp> wrote: >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 If you are compute bound, then ya want "kernel threads" so you can be scheduled to multiple CPUs at once. If you aren't, then since you are in the kernel anyway, there is no point of keeping everything in userland. So both kinds of activity warrant "kernel threads" IMHO. >> - 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 But switching kernel supported threads would be simpler than the complexity of a whiz-bang upcall KEC mechanism. I bet people would find more bugs in the latter. >Are there certain applications better handled by pure kernel threads and Computer bound apps would do better with kernel scheduled entities on SMP machines. >others better handled by a dual concurrency implementation? DJS