Date: Tue, 08 Aug 1995 08:29:34 EDT From: Christopher Provenzano <proven@MIT.EDU> To: Bakul Shah <bakul@netcom.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Threads Message-ID: <9508081229.AA19143@jimi.MIT.EDU> In-Reply-To: Your message of "Thu, 03 Aug 1995 07:54:00 PDT." <199508031454.HAA29601@netcom14.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > What you have just described are a set of threads of scope process, > > and decided to call them kernel threads. They fit perfectly well in > > the POSIX model. They also do not need to be in the kernel. They may > > need some additional kernel support such as ASYNC I/O but for the most > > part they can be implemented as a library. > > I don't think so. Allow me to illustrate schedule groups > with an example. > > Let A1, A2, A3 be threads in the same process (i.e. share > the same execution enviroment), B1, B2 be threads in another > process. If the system supported `schedule groups' as I > envision them, I would be able to put A1, A2 & B1 in one > group and A3 & B2 in another group. Time spent by any > thread in a given schedule group (and regardless of which > process it comes from) is debited against the entire group > and that threads in a group may simulteneously run on more > than one processor (until they all block or the group's > allotted time slice expires or a higher priority group > becomes ready to run). In this scheme of things > realtimeness becomes a property of a schedule group, not a > process or a thread. > > To switch from A2 to B1 you have to invoke a kernel call. > Ditto if you want to run on more than one processor. > > There are benefits to putting threads of different processes > in the same group or from same process in different groups: > a multi-process app. is likely to use related resources. On > a traditional time-sharing system you may want to limit time > hogged by a single user. A `server' may have some realtime > threads (e.g. deliver video) and some non realtime threads > (e.g. start a new video stream thread). > > Mind you, I am not saying schedule groups are the way to go > or any better than pthreads; merely that the problem of a > little ls process compteting against a horde of 10000 > threads can be solved in a different way (from pthreads). Let me rephrase the original problem. Come up with a way of handeling 10000 threads. I don't think any solution where the kernel schedules, or even just knows about all the threads will work. I do think that what you have described is similar to what I envision for pthreads once you solve the problem of 10000 threads. See below. > > I think of kernel threads as threads scheduled against other > > kernel threads. (Each standard Unix process has a kernel thread.) > > So one threaded process with ten kernel threads has ten times > > the scheduling entities as a standard process. For some applications > > this might be ok but to not regulate it is asking for disaster. This > > is my big argument against just kernel threads. I feel you need both > > kernel threads and user threads. > > I will point you back to the idea of schedule groups (I am > sure someone has already explored this idea, probably under > a different name). A restructuring of the kernel data > structure(s) of a standard Unix process is needed for kernel > threads in any case: threads within a process share process- > wide tables. In a similar fashion one can split out > scheduling related stuff in a separate structure and have > all threads in the same schedule group share that structure. The idea of schedule groups is not new and I have had a similar idea for a while for the interaction between kernel threads and user threads An example is a process with four kernel threads K1 - K4, and seven user threads U1 - U7. A grouping could be as follows. K1 : U1 K2 : U2, U3 K3, K4 : U4 - U7 The first group is the typical one to one mapping of a kernel thread to user thread, the second is a typical many user threads mapped on one kernel thread and the third is many user threads shared between many kernel threads (ala SMP in a process). Kernel threads are scheduled against all other kernel threads (and standard processes). User threads are only scheduled against other user threads within a group. CAP
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508081229.AA19143>