Date: Wed, 24 Nov 1999 14:57:54 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Daniel Eischen <eischen@vigrid.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@newsguy.com>, Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911241957.OAA42011@whizzo.transsys.com> In-Reply-To: Your message of "Wed, 24 Nov 1999 14:29:12 EST." <Pine.SUN.3.91.991124141640.316A-100000@pcnet1.pcnet.com> References: <Pine.SUN.3.91.991124141640.316A-100000@pcnet1.pcnet.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? Wow, so this has turned way too complicated. I confess to having the same basic questions as Matt; why all this complexity? I think the answer is that there's a belief that having the kernel context switch between threads is too expensive, thus the desire to multiplex "user" threads on to fewer "kernel scheduled" threads. To answer your question: I think the question you're asking doesn't make any sense. I think Matt was proposing that there's simply a kernel thread context that exists for each and every "user" thread that's active in the application. Today, there's only one of these that's intimately associated with the process context (contains MMU/VM cntext, file descriptors, etc.) > 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. Why? If someone has done measurements comparing the different approaches, and show that there's too much "overhead", then that's great. But it appears that there's a considerable price to be paid in additional complexity by sticking a user-mode thread library with it. I ask simply because in my prior experiences with multi-threaded operating systems, there was no such thread multiplexing happening in user space. Certain my NeXTSTEP based system, running on a crummy 25MHz 68040 didn't die from the "overhead". And previously to that, on old UNIVAC 1100 series mainframes, there certainly wasn't any such thing going on. Their idea of "lightweight" threads (they called them "activities") had a reduced register set to save on context switching overhead. Wouldn't you have minimal support for non-multiplexed threads first? For many applications with just a handful of threads, the "overhead" issue probably isn't even noticable. And I just hate to think of the crocks that debuggers will need to have to be aware of this thread multiplexing going on in user space. louie 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?199911241957.OAA42011>