From owner-freebsd-arch Fri Nov 12 4:51:31 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 87BD414BEC for ; Fri, 12 Nov 1999 04:51:28 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA16159 for ; Fri, 12 Nov 1999 13:51:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA26336 for freebsd-arch@freebsd.org; Fri, 12 Nov 1999 13:51:27 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 146E614BEC for ; Fri, 12 Nov 1999 04:19:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt33.pcnet.net [206.105.29.107]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA05359; Fri, 12 Nov 1999 07:17:47 -0500 (EST) Message-ID: <382C0599.1E95429B@vigrid.com> Date: Fri, 12 Nov 1999 07:18:33 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Michael Schuster - TSC SunOS Germany , "freebsd-arch@FreeBSD.ORG" Subject: Re: Threads goals and implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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