Date: Sun, 31 Oct 1999 16:40:27 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199910312340.QAA12893@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9910311201120.8816-100000@home.elischer.org> References: <Pine.BSF.4.05.9910311156210.8816-100000@home.elischer.org> <Pine.BSF.4.05.9910311201120.8816-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> ------------ 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. I think this can be dropped, since it's both confusing and almost contradictory. There is no such way to 'block' a regular process, although one can stop it in Unix, so the issue of blocking implies a blocking on something, which is allowed. > 4/ All threads see the same address space (exactly). > > 5/ All threads share the same file resources. All threads share all the same resources (except for thread-specific stack). > 6/ (contentious) multiple theads should be bound to within the resource > limits of the single process. I'll leave that up to others if that's a good idea. > 7/ Some well documeted scheme exists for handling signals and othe rasync > events. I think this is one of the 'hard problems' to solve. > 8/ Exit/shutdown protocol is well defined. Agreed. > 9/ there exists a set of primatives that allow threads to influence the > in-process scheduling between themselves. Agreed, see #2. > 10/ your ideas here. Note, you an also suggest that I remove an idea. The ability for a process to have multiple threads active in the kernel (system calls) without stopping the process the threads are busy in. > 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. While I agree this 'simplistic' approach isn't as good as a N-M approach, it's certainly better than what we have now. Is anyone working on the more complex model *at all*, cause if not I'd like to see a simple kernel threading model used, cause something is better than nothing. Nate 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?199910312340.QAA12893>