Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Nov 1999 14:29:12 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@newsguy.com>, Julian Elischer <julian@whistle.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org
Subject:   Re: Threads
Message-ID:  <Pine.SUN.3.91.991124141640.316A-100000@pcnet1.pcnet.com>
In-Reply-To: <199911241905.LAA20045@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Nov 1999, Matthew Dillon wrote:

> :In this context, what is a task?  Something similar to a kernel thread?
> :If there are N (user-level POSIX) threads in an application, how many 
> :tasks are there?
> 
>     N.  A task is simply an execution context for the scheduler.  That's it,
>     nothing special.  The scheduler need only know about tasks and doesn't 
>     really have to know about meta-data such as (except for the MMU context)
>     data stored in Processes, nor does it really need to know what *kind*
>     of task it is messing with.  
> 
>     Simplicity is the best solution.
> 
> :>     complicates the code.  We can trivially use the existing priority 
> :>     scheme to schedule interrupt tasks (threads).
> :
> :The kernel doesn't know at what priority the threads run, so how can
> :it effectively schedule them?
> :
> :Dan Eischen
> 
>     If you have one Task == one Thread, the priority is in the Task
>     structure, so the kernel would know.  Obviously the scheduler must know
>     or it can't properly schedule the execution context.

So everytime the UTS wants to run a new thread, it has to make a call
to the kernel to tell it what it's current priority is?  And the kernel
is suppose to be able to handle SCHED_FIFO and SCHED_RR queueing?  And
the kernel will now if a task holds a critical resource and will be
able to avoid priority inversions?

I think we want to avoid having the kernel know too much about each
thread.  It is something that is more easily handled in the threads
library.

Dan Eischen
eischen@vigrid.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.991124141640.316A-100000>