From owner-freebsd-arch Sun Oct 31 15:53:12 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 3AA1014F7B for ; Sun, 31 Oct 1999 15:53:05 -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 AAA22793 for ; Mon, 1 Nov 1999 00:53:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA68027 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 00:53:03 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1789F14F7B for ; Sun, 31 Oct 1999 15:45:18 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA24146; Sun, 31 Oct 1999 18:44:02 -0500 (EST) Date: Sun, 31 Oct 1999 18:44:02 -0500 (EST) From: Daniel Eischen Message-Id: <199910312344.SAA24146@pcnet1.pcnet.com> To: freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads models and FreeBSD. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ------------ 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. 11.) Ability for the threads library to cancel/terminate a thread blocked in the kernel. 12.) A libpthread that can be linked with libc. 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. 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 ;) 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: o Modify the sleep queue to queue wait_node entities, not procs. A wait_node would consist of at least a boolean flag and a proc or thread pointer to support queueing of threads or procs. o Modify mi_switch to call mi_context_switch for a multi-threaded process. When a process blocks in the kernel, mi_context_switch saves the user and kernel context, switches to a predetermined kernel/user context and makes an upcall to the threads library notifying it of the event. The library returns with another thread to run. o Allow for maintaining (off proc) a queue of kernel contexts (at least one for each blocked thread, one for each currently running thread, and one for the upcall notification). The kernel context would consist of at least a kernel stack, kernel register set save area, and a pointer to the user-land ucontext/thread. You would also hang the list of LWPs off the parent proc, and be able to determine which LWPs are being used or not used. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message