From owner-freebsd-arch Sun Oct 31 17:42:14 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 9BF0814C01 for ; Sun, 31 Oct 1999 17:42:11 -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 CAA27561 for ; Mon, 1 Nov 1999 02:42:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA69085 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 02:42:10 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 04B8114C01 for ; Sun, 31 Oct 1999 17:41:41 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA29024; Sun, 31 Oct 1999 17:41:38 -0800 (PST) Date: Sun, 31 Oct 1999 17:41:35 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Daniel Eischen Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. In-Reply-To: <199910312344.SAA24146@pcnet1.pcnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 Oct 1999, Daniel Eischen wrote: > > ------------ Thread properties ----------- > > 1/ Multiple independent 'threads of control' within a single process > > at user level. The most basic quality of threads. > > > > 2/ Ability to simultaneously schedule two threads over separate > > Processors. > > > > 3/ Inability of one thread to block aother thread unless they are > > intentionally synchronising. > > > > 4/ All threads see the same address space (exactly). > > > > 5/ All threads share the same file resources. > > > > 6/ (contentious) multiple theads should be bound to within the resource > > limits of the single process. > > > > 7/ Some well documeted scheme exists for handling signals and othe rasync > > events. > > > > 8/ Exit/shutdown protocol is well defined. > > > > 9/ there exists a set of primatives that allow threads to influence the > > in-process scheduling between themselves. > > In no order of importance: > > 10.) Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. > fair enough.. (though very much a 'request' than a major design goal) > 11.) Ability for the threads library to cancel/terminate a thread > blocked in the kernel. oooooh > > 12.) A libpthread that can be linked with libc. At this stage, an implementation detail, can I leave this till a later stage? > > 13.) Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. I see I need to start a 'user-land properties' list. > > Desired: > > 1.) Ability for the threads library to determine the scheduling model. > This is one advantage of scheduler activations. The threads library > is informed when a thread blocks or unblocks in the kernel and > decides which thread runs next. This also solves the priority > inversion locking problem (3/) because the threads library can > determine if a swapped out thread was in a critical region. In > this case, the thread is resumed on the next available LWP and > can be made to yield immediately upon exiting the critical region. > I guess this is more my desire, but what the heck ;) Can you look a tteh re-written goals (posted soon) and try express this more simply? > > 2.) Ability for an application to bind a thread to a lightweight > process as well as to a CPU. > > 3.) Ability to have M by N threads over processes, where M and N > can be determined by the application. > > 4.) Ability for the application to specify one or more LWP-bound > threads be run in a different scheduling class than the rest > of the threads in the application. > > > What we have at the moment: > > > [...] > > If you are going to say "support pthreads" I'd like you to instead break > > that down to what we need to have in order to support pthreads.. I want > > pthreads to be a by-product (almost) of a good threading model, not the > > design goal. > > I really think that scheduler activations are the way to go instead > of the LinuxThreads approach. I also think it's better than async > call gates because the application can have explicit control of the > number of LWPs and threads, and the threads library has total control > of scheduling. > > Some basic kernel changes in order to support scheduler activations: [...] Very nice but you're jumping the gun here.. > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message