Date: Wed, 01 Dec 1999 17:03:57 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-arch@freebsd.org Subject: Re: Threads stuff Message-ID: <38459B4D.B922D168@vigrid.com> References: <Pine.BSF.4.10.9911282113490.544-100000@current1.whistle.com> <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> <199911301841.KAA26600@apollo.backplane.com> <38455430.C3CF72BD@vigrid.com> <199912011734.JAA34126@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > > :Under your proposal, is there a 1:1 correspondence of user (POSIX) > :threads to kernel threads, or does the UTS simply see kernel threads > :(instead of rfork'd processes) as the entity onto which user threads > :are scheduled? > > Yes, there is a 1:1 correspondence. But the runnability of a thread > is controlled by the UTS, not the kernel. So, for example, if you > have 10 runnable threads and the UTS is implementing a serialized FIFO > scheduling class for all 10 threads,t he UTS will only tell the kernel > to schedule one thread at a time. If the UTS is implementing a > standard multi-processor model, the UTS will tell the kernel to schedule > N threads at a time, where N is the number of virtual cpu's the UTS > wishes to simulate. If N == X, where X is the actual number of cpu's > in the system, then the simulation happens to reflect reality. > > :In earlier email you had stated that kernel threads would be limited > :to the resources of the governing process. One of our goals is to > :be able to create thread groups that can have their own slice of > :CPU, scheduling class and priority. How does this work under your > :proposal? > > To get your own slice of CPU you can still rfork() just fine. That is, > rfork() can be done as a concious decision and does not need to be > done to simulate concurrency or to implement a *thread* scheduling class. OK suppose we rfork to get PTHREAD_SCOPE_SYSTEM threads or a different scheduling class. Is there still one "special management" thread or are there now two? The UTS needs to adjust scheduling of threads across the rfork'd processes. > :One of the things that I like about SA is that locking can be done > :in userland because the UTS is notified when preemptions occur. Your > :method doesn't include upcalls, so how would locking be done? > : > :Dan Eischen > :eischen@vigrid.com > > You can still do locking in userland. A userland lock simply calls the > UTS synchronously when it blocks. No upcall is required. Suppose a thread tries to take a lock and fails. It is suppose to make a synchronous call to the UTS to inform it that the thread is waiting on the lock? How does the UTS resolve the problem so that the owner of the lock (which the UTS may not know) continues to run until it releases the lock. 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?38459B4D.B922D168>