*BSD News Article 90016


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