Date: Wed, 24 Nov 1999 11:48:00 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Daniel Eischen <eischen@vigrid.com> Cc: "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: <199911241948.LAA20277@apollo.backplane.com> References: <Pine.SUN.3.91.991124141640.316A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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?
The simple answer is: Yes. Of course, if you are already in the kernel
making a call to the scheduler costs nothing. If you aren't, the cost
is a microsecond or so (assuming all the other junk FreeBSD does in the
critical path is removed - stuff that doesn't have to be there).
The reason you want to implement threads in the kernel is because it
gives you much greater flexibility, especially when threads are issuing
I/O. Remember that most thread switches occur due to event blocking,
and event blocking already requires the kernel no matter how fancy you
get with asynchronous system calls.
This doesn't prevent you from having a user-level thread scheduler, it
simply means that the UTS must make a system call to specifically schedule
the next thread for a processor if it wants to be the one to choose it.
: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
I agree to a degree. For basic threading schemes I think simply using
native threads supported by the kernel is the way to go. If you want to
implement special schemes that is something a UTS could do very easily
with very little kernel support.
-Matt
Matthew Dillon
<dillon@backplane.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?199911241948.LAA20277>