Date: Sun, 31 Oct 1999 18:58:59 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Nate Williams <nate@mt.sri.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II Message-ID: <Pine.BSF.4.05.9910311852310.8816-100000@home.elischer.org> In-Reply-To: <199911010225.TAA14010@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Oct 1999, Nate Williams wrote: > > ---Possible system design goals of system threads support -- > > --- Note just becasue something is in this list doesn't mean that > > it will be done, just that it's going o be carried forward to > > further discussion. > > -------------------------------------------------------------- > > > > 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. > > 2A/ ability to tune and control the above.. > > > > 3/ One blocking thread cannot block another thread. > > Blocking of one thread does not imply that other threads be > > blocked. > > How about instead of 'cannot' we use the word 'does not necessarily' > block another thread, and then append 'unless it does using programatic > means'. > > Cannot implies some sort of bad thing. I'm trying to say that "just because one thread blocks, doesn't mean that the others can't keep running"! Will that do? > > > 4/ All threads see the same address space (exactly). > > I like this. > > > 5/ All threads share the same file resources. > > How about 'process' resources instead? It's more than files that they > share... 4/ All threads in a processs see the same address space (exactly). 5/ All threads in a process share the same system resources. > > 10/ Quick access to curthread and thread specific data. We shouldn't > > have to enter the kernel to get this. This should also be true > > for threads spread across multiple [lightweight] processes. > > The last sentence is redundant, since threads are by definition > lightweight processes. :) 10/ Quick access to curthread and thread specific data. > > > 11/ Ability for the threads library to cancel/terminate a thread > > blocked in the kernel. > > See previous email. See previous clarification.. :-) I think a way to ask a thread to 'wake up and back out' is what's required. > > > > Nate > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910311852310.8816-100000>