From owner-freebsd-arch Fri Nov 12 0:33:35 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 005A214C09 for ; Fri, 12 Nov 1999 00:33: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 JAA11888 for ; Fri, 12 Nov 1999 09:33:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA16587 for freebsd-arch@freebsd.org; Fri, 12 Nov 1999 09:33:26 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7E74D14CEB for ; Fri, 12 Nov 1999 00:33:09 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id BAA05953; Fri, 12 Nov 1999 01:33:03 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id BAA17766; Fri, 12 Nov 1999 01:33:02 -0700 Date: Fri, 12 Nov 1999 01:33:02 -0700 Message-Id: <199911120833.BAA17766@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Michael Schuster - TSC SunOS Germany , "freebsd-arch@FreeBSD.ORG" Subject: Re: Threads goals and implementation In-Reply-To: References: <382ABB1A.CB959F01@germany.sun.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 10/ A method to ask a thread blocked in the kernel to wake up and back > out (similar to present 'signals'). (see 6, 7) I think this is a good addition. > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. > 3/ see 8 above. > --------------------------- > > Implementation: > > 1/ User-level thread scheduler that can perform user-level thread (ULT) > context switches. The ULT that is running on a KSE is completely > opaque to the kernel. > > 2/ The kernel provides KSEs to a process in which ULTs may be run. > Multiple KSEs may be provided to a process in order to achieve > simultaneous SMP executions and to allow ULTs to obtain separate > system resource limits. > > 2A/ Some code to manage assigments of KSEs to processes and CPUs will be > needed. > > 3/ Kernel structures (proc, sleep queues, run queues?) will need to > change to support KSEs and multiple threads per process being > blocked in the kernel. It seems that struct proc should be analyzed > to classify components as being relevant to the process, KSEs, or > "context being blocked in the kernel". > 4/ Exceptions may be one way to accomplish thread 'signals', as well as a good way to have the thread 'back out' of kernel context if it is abnormally terminated. > 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)(*) How does the kernel re-assign an KSE that corresponds to a blocked thread *IF* the user-land scheduler (or some other active thread) wakes it up abnormally (or otherwise). Does the waking thread lose it's quantum? (Note, I think this is a bad idea in most cases, since what often happens with 'blocked' threads is this.) aquire_resource(); do_something(); wake_waiting_thread(); release_resource(); Note, you must wake the waiting thread while holding onto the resource, so if we wake the waiting thread by giving up our KSE, that thread should still be 'blocked' until we give up the critical resource. So, the 'wakeup' in the normal case is really an event that shouldn't be delivered until *after* the current thread loses it's resource. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message