From owner-freebsd-arch Tue Nov 30 8:55:43 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 BFE5514CE3 for ; Tue, 30 Nov 1999 08:55:39 -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 RAA08735 for ; Tue, 30 Nov 1999 17:55:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA71227 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 17:55:37 +0100 (MET) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by hub.freebsd.org (Postfix) with ESMTP id 239C81597F for ; Tue, 30 Nov 1999 08:54:32 -0800 (PST) (envelope-from pulsifer@mediaone.net) Received: from ahp3 (ahp.ne.mediaone.net [24.128.184.250]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id LAA15035 for ; Tue, 30 Nov 1999 11:54:31 -0500 (EST) From: "Allen Pulsifer" To: Subject: RE: Revisitted.. Threads goals.? Date: Tue, 30 Nov 1999 11:54:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please forgive me for sticking my foot into this conversation. I'm new to FreeBSD and have only been following this conversation for a week. I don't pretend to know a lot of the theory, or even how threads and SMP are currently implremented in FreeBSD. Everything I could possibly add to this discussion is probably already assumed and well understood by the people on this list, but sometimes it helps to restate the obvious. If not, please feel free to hit the delete key. To step back even further from what Julian just said, the purpose of implementing threads is to have a resource- efficient method of multitasking. Unix operating systems traditionally use processes to implement multitasking. The process structure provides for system security (via separate, virtual address spaces), fair sharing of resources (via round robin scheduling) and efficient use of resources (via blocking and task switching). However, the implementation of processes makes them resource intensive. They are expensive to create, take a lot of memory, expensive to manage (switch from one to another) and can only communicate with each other primarily though expensive methods such as IPC. [Have I left anything out?] The purpose of threads is to provide a more efficient method of multitasking. The goals of threads are to: 1) minimize the amount of memory that each thread uses, so that many (thousands?) of threads can be created; 2) minimize the amount of work that must be done to switch between treads (both scheduling work and actual task switching); 3) allow threads to efficiently communicate with each other; 4) perform all of the above while still providing system security, and fair and efficient use of resources. To meet these goals, it seems obvious that process structure would be maintained. This allows system security to be maintained, and may also allow fair use of resources to be maintained. (The latter is what Julian is arguing for.) It would also seem obvious that threads must share the same address space. This allows efficient communication between threads, as well as efficient task switching between two threads that share the same address space. (But of course, it doesn't help threads with separate address spaces, and this has implications for optimal thead scheduling.) Given the above, it would finally seem obvious that threads sharing the same address space would live within the same process, and possibly inherit all the rest of the baggage that comes along with that (PID, etc). Part of the discussion that is going on seems to be simply about what things do threads share and what things do they not share. For example, each thread must have its own CPU state (PC, registers, etc) and thread (or user) stack so that it can be executed and suspended as needed. However, all threads associated with a process share the same memory map. Other items may be shared or not shared depending on what you are trying to accomplish. A lot of the decisions are tradeoffs between functionality and efficiency. For example, it would seem desirable to make the unshared structures as small as possible, to minimize memory use; however, that may sacrifice functionality. I am not familiar with all of the structures involved, but maybe someone would make a list: what structures must absolutely be unshared, and what structures can optionally be made unique, and what features or functionality are gained by making them unique? A list like this would assist in the tradeoff analysis and decision making. Implementation details aside, it seems to me that one of the major points Matt Dillion is looking for is the ability for two threads, bound to the same process, to run simultaneously on two different CPU's. This seems to be a very desirable goal, however, the question seems to be, what is the cost of implementing this in terms of complexity and level of effort? Furthermore, while this feature would seem to be desireable, if it were NOT implemented, there maybe some assumptions that could be made by user programs and shared libraries that would make the use of the system less complex and more efficient. For example, if it is guaranteed that two threads bound to a process cannot be executing simultaneously, does that simplify user programming? In addition, if it is guaranteed that a thread will not surrender the CPU to another thread in its same process except at certain well defined times (a voluntary surrender, a system call, a signal) does that simplify user programming even more? Do these gains in simplicity make it worthwile not implementing what might otherwise be a powerful feature? Finally, Matt seems to making some points about how the kernel itself can make use of threads. I admit I don't have the background to understand what he is saying. But aside from having "user" threads run in both user and kernel mode, is it envisioned that the kernel itself will have threads that aren't bound to any user process? Where will those threads be used and how will they be managed? Regardless of whether two "user" or process threads can run simultaneously on two seprate CPU's, it would still seem desireable to allow two purely kernel threads to do this. I know everyone who is active on this list is ten times more knowledgeble and experienced than I am, but I hope some of these thoughts (none of which haven't been said somewhere before) might be helpful. Allen > -----Original Message----- > From: owner-freebsd-arch@FreeBSD.ORG > [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of Julian Elischer > Sent: Tuesday, November 30, 1999 1:45 AM > To: freebsd-arch@FreeBSD.ORG > Subject: Revisitted.. Threads goals.? > > > > I think this is a good time for us to re-examine some of the things that > we decided were goals. > > I have somme comments I'd like to make AT THE END, but after the general > neuron frying of the last week or so it might be a good idea to look at > these again and see if any of them have changed in light of the > discussion. I have difficulty in seeing this list as exhaustive or > correct. We need someone who is very into threads to contribute. > Jason? What do yuo see as YOUR goals? > > > -----last version of the goals I have in my mailbox.---- > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. > 2A/ ability to tune and control the above.. > > 3/ Just because one thread blocks, doesn't mean that > the others can't keep running. > > 4/ All threads in a processs see the same address space (exactly). > 4A/ All threads in a process share the same system resources, except cpu > which is treated specially, and some as yet unspecified thread > specific uniqifier. > > 5/ A process may be able to group threads into classes that have > different system priorities. These classes can not have priorities > greater than the process itself or a child could achieve, and should > be treatable by the system as a separate child process from a > scheduling point of view (including limits). > 5A/ As a result threaded processes should have no more capability to > swamp a system than a regular forking process. > > 6/ Some well documeted scheme exists for handling signals and other > async events. > > 7/ Exit/shutdown protocol is well defined. > > 8/ The allocation of user level threads to thread groups is opaque to the > kernel. > > 9/ Quick access to curthread and thread specific data. > > 10/ A method to ask a thread blocked in the kernel to wake up and back > out (similar to present 'signals'). (see 6, 7) > > > ---- 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. > > ------------- > Meta-goals > ------------- > We should keep our eyes on: > *) scalability > *) performance > *) ability to support features required by standards based threads. > *) ability to support features of those thread packages we select as > needed. > --------------------------- > COMMENTS: > > Peter made a valid point which is that maybe we should figure out > a waypoint between here and there, that gives us a working but > sub-optimal threads package of the order of the linux threads package, > that can be included in 4.0 > > We may have 2 whole months to get that done :-( > > > Also, Matt Dillon has been arguing strongly that point 8 (kernel) > and point 3(user) are non goals, in fact he wants the opposite. > He also argues that making an entity that groups KSE's on a scale smaller > than the entire process is a bad idea. I disagree but we haven't > decided anyting yet. He claims 'simplicity. I think that he may be sliding > back up teh other side of th ecurve by trying to simplify more than the > goals (many of which we are inherritting from Posix via the 3rd meta-goal) > allow. > > how would we move towards Peter's hope? and are there things we can do > that there is no argument about? I think that separating the proc > structure is agreed, but it is not needed for Linux threads.. > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message