Date: Sun, 31 Oct 1999 13:15:23 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: freebsd-arch@freebsd.org Subject: Threads models and FreeBSD. Message-ID: <Pine.BSF.4.05.9910311201120.8816-100000@home.elischer.org> In-Reply-To: <Pine.BSF.4.05.9910311156210.8816-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ------------ 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. 10/ your ideas here. Note, you an also suggest that I remove an idea. ------------- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910311201120.8816-100000>