Date: Wed, 24 Nov 1999 11:55:14 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911241148120.11412-100000@current1.whistle.com> In-Reply-To: <199911241835.KAA19645@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Nov 1999, Matthew Dillon wrote: > > :Julian, Dan, remember that reducing the overhead of task switching > :(thread switching) is of vital importance. In that light, the least > :context that has to be save/restored when a KSE blocks, the better. > : > :-- > :Daniel C. Sobral (8-DCS) > :dcs@newsguy.com > :dcs@freebsd.org > > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. This is 'linux threads', and it's what we already have, using rfork() however it's very heavyweight when compared with pure userland threads. you need something in-between, to get the advantages of both kernel support (blockable syscalls and page-faults) and the ability to schedule 1000 tiny threads effficiently (which is the model that some threaded packages use). > > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. We basically already havee that, but you need to have the ability to involve teh User Thread Scheduler in process restarts etc. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). well I agree with you to a point..And we are not planning on separate scheduling queues for threads and normal processes. Basically threads are assigned to a parent process, which is treated pretty much as it is now in a lot of ways. > > -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?Pine.BSF.4.10.9911241148120.11412-100000>