From owner-freebsd-arch Tue Nov 2 1: 0:33 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 28A8614E79 for ; Tue, 2 Nov 1999 01:00:21 -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 KAA14702 for ; Tue, 2 Nov 1999 10:00:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA78400 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 10:00:17 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 536DE14F34 for ; Tue, 2 Nov 1999 00:59:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id AAA79439 for ; Tue, 2 Nov 1999 00:59:28 -0800 (PST) Date: Tue, 2 Nov 1999 00:59:28 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Threads models and FreeBSD. (Next Step) 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 Here is an updated version of the rather simplistic requirements for a threads model for freeBSD. New requirements can be added as we go along but these should give us tomething to go on.. Now, we need to start collecting alternative implementations that might satisfy these goals. We should gathe rinformation on these and READ teh literature and code, before discussinghtese too much. getting into arguments at this stage will not help the process. We have 4 starters at this point. Note, they MAY NOT BE mutually exclusive! 1/ The scheme we've been working towards for a while due to lack of suggested alternatives.. rfork based processes sharing resources. This is very similar to the Linuxthreads implementation. one kernel schedulable entity (light process) per thread. 1A/ actually use the linuxthread code.. 2/ A variant of (1) where blocking processes somehow signal a userland action that starts another thread in another rfork'd process. I have heard rumours that someone was looking at this. Could they own up? 3/ The much referenced paper on "Scheduler activations" Everyone should read this paper as homework (It's referenced below) before participating further in this disussion. 4/ Terry's schem. (similar in some ways to (3) but not the same.. TERRY's homework is to write it down. 5/ Any more schemes paple know of, can go here. julian [1st reposting, (with changes)] ------------------------------------ This article will be reposted again for late comers in the discussion thread: There are several properties of threads that make them both good and bad programming models. John Ousterhout gave a keynote at Usenix a couple of years ago titled "threads considered harmful", which was both ammusing and had more that a shred of truth to it. Having said that, good thread support is essential able to support a lot of modern programs, and is a good way of ensuring that processes can make use of the increasing amount of MP machinery that is available. So what are the definitions that a thread enabled environment should possess? This not a definative list, and before we go on to solve the worlds threading problems, I'd like everyone to add their thoughts to this list so that we can agree about what problems we are trying to solve. 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. -------------------------------------------------------------- 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). 5/ All threads in a process share the same system 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 other async 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. 9A/ e.g. 'per thread' Thread scheduling classes. 10/ Quick access to curthread and thread specific data. 11/ A method to ask a thread blocked in the kernel to wake up and back out. (similar to present 'signals') 12/ Processorr affinity for threads. ---- 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. ------------- 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 therad packages we select as needed. --- refs: http://www.freebsd.org/~deischen/p95-anderson.pdf http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1 999/freebsd-current/19990321.freebsd-current http://lt.tar.com/ ------------------------------------- ------------- What we have at the moment: John Birrell's excelent work on user-level threading (libc_r), based originally on Chris provenzo's threading code has given us quite a bit of mileage so far, but it's starting to run out of steam with new requirements being more certain about kernel support requirements. It is notable that we already support Linux kernel threads on FreeBSD better than we support a native threads model. This is because we support the 'clone' system call through our rfork() code, and that is their basis for threading. As is common for this group of people, we have not adopted the Linux approach because it is considered to be 'too simplistic', assigning a separate kernel schedulable process to run each thread. Having said that, Amancio Hasty at one stage wrote a set of threading primitives to allow Kafe to run on FreeBSD using this scheme of threading, and Richard Seaman has a port of the Linuxthreads code to freeBSD at his website, http://lt.tar.com/ . This represents a useful piece of work and though it is presently not working on -current, hopefully this will be fixed soon. I believe there may be problems with the new signal stuff though I have not tested it myself. I also reference the following email in the archives: http://www.freebsd.org/cgi/getmsg.cgi?fetch=25000+30231+/usr/local/www/db/text/1999/freebsd-current/19990321.freebsd-current Peter dufault also has some work on scheduling that may be slightly relevent. 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