Date: Fri, 12 Nov 1999 07:18:33 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com>, "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <382C0599.1E95429B@vigrid.com> References: <Pine.BSF.4.10.9911112314520.17452-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Here are my ideas. The terminology is not fixed. > > A PROCESS is the holder of all resources related to a single address > space. The SA paper liked to call this an "Address Space" but I think we > want to emphasise it's realtionship to a regular unix process. > > The PROCESS may 'fork' off several SUBPROCESSES. These share the resources > of the process with the exception of their scheduling characteristics. > >From a scheduling perspective they are the equivalent of child processes. > > Each SUBPROCESS is allocated one or more KERNEL SCHEDULABLE ENTITIES > (KSE's). KSE' may be added to or removed from a SUBPROCESS as needed to > prevent it from involuntarily block (except when it's quantum is exceeded)(*) > > The USER THREAD SCHEDULER assignes thread to KSE's and is aware of all > threads entering and exiting the kernel. No, it is only aware of threads that block and unblock in the kernel. The UTS should not know about _all_ kernel entry points, only those entry points that are cancellable. I suppose that it is possible that the mechanism used to notify the UTS of a thread blocking in the kernel could also include the system call id/number in which the thread was blocked, but it's not necessary from the UTS point of view. > It can release KSE's and handle > the case when a KSE blocks and another is provided as a replacement, It > is probably also aware when a KSE is prempted (though only when that > PROCESS is next run) (i.e. control returns to the UTS, withthe thread's > state available, rather than directly to the thread. The UTS can chose to > load that state adn keep running, or allow some other thread to run, > depending upon whether there are deadlock or similar ramifications. > > KSE's from several SUBPROCESSSES may be running simultaniously in an SMP > system, but which threads are in them is decided by the UTS. > > We may need to implement THREAD system calls through a different callgate > to allow the different call/return convensions. I don't see why this would be necessary. A separate system call to notify the kernel that the process and/or KSEs are using SAs (or whatever we decide on) is sufficient. The UTS would also have to inform the kernel of the user-level routines to use for event notification, so this would probably be sufficient for marking a process as needing different call/return conversions (SAs). I have a question. How do we manage kernel contexts in the kernel? How many threads are allowed to be blocked in the kernel at any one time? Each thread blocked in the kernel uses a resource (probably some structure with a kernel register save area, a TAILQ/LIST entry or two, etc), and this should be constrained in some way. Should pthread_setconcurrency(3) adjust the number of kernel contexts assigned to a process? 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?382C0599.1E95429B>