Date: Sun, 31 Oct 1999 17:09:15 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Nate Williams <nate@mt.sri.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <Pine.BSF.4.05.9910311652000.8816-100000@home.elischer.org> In-Reply-To: <199910312340.QAA12893@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Oct 1999, Nate Williams wrote: > > ------------ 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. What this means is that if one thread does a read() and blocks, the other threads don't all block. maybe I should reword it to: "Inability of one thread to unwittingly block another thread during normal operations" ? > > > 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). Well they can see all the other stacks, they just don't use them as the stack. How would you better word that? > > > 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. It's certainly something to be optioanlly allowed if not by default, otherwise 100 threads can allow a single process to hog an entire system. > > > 7/ Some well documeted scheme exists for handling signals and other > > async events. > > I think this is one of the 'hard problems' to solve. As one of the "hard problems" it's received lot of work. Who has done some reading on this topic? > > 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. This is the one I had as #3 that you objected to. Obviously I need to work on the wording.. And of course having multiple treads ACTIVE in the kernel is a different (SMP) project.. Obviously a thread runs within the kernel without being pre-empted by the userland thread scheduler, so that all but one of the threads in the kernel must be sleeping. > > > 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. Richard seaman's work is available. it can be used prety much without change.. Do we want to do that? I think the libc_r guys should be left to make that decision, but possibly having a simple underlying mechanism now while we work on the better one might be good idea.... but this is getting ahead of our selves.. let's get the requirements down first.. I will repost a modilfied version of the requirements in a second incorporating suggestions. julian > > > > 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?Pine.BSF.4.05.9910311652000.8816-100000>