Date: Sun, 31 Oct 1999 17:41:35 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <Pine.BSF.4.05.9910311727080.8816-100000@home.elischer.org> In-Reply-To: <199910312344.SAA24146@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Oct 1999, Daniel Eischen 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. > > > > 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. > > In no order of importance: > > 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. > fair enough.. (though very much a 'request' than a major design goal) > 11.) Ability for the threads library to cancel/terminate a thread > blocked in the kernel. oooooh > > 12.) A libpthread that can be linked with libc. At this stage, an implementation detail, can I leave this till a later stage? > > 13.) Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. I see I need to start a 'user-land properties' list. > > Desired: > > 1.) Ability for the threads library to determine the scheduling model. > This is one advantage of scheduler activations. The threads library > is informed when a thread blocks or unblocks in the kernel and > decides which thread runs next. This also solves the priority > inversion locking problem (3/) because the threads library can > determine if a swapped out thread was in a critical region. In > this case, the thread is resumed on the next available LWP and > can be made to yield immediately upon exiting the critical region. > I guess this is more my desire, but what the heck ;) Can you look a tteh re-written goals (posted soon) and try express this more simply? > > 2.) Ability for an application to bind a thread to a lightweight > process as well as to a CPU. > > 3.) Ability to have M by N threads over processes, where M and N > can be determined by the application. > > 4.) Ability for the application to specify one or more LWP-bound > threads be run in a different scheduling class than the rest > of the threads in the application. > > > What we have at the moment: > > > [...] > > 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. > > I really think that scheduler activations are the way to go instead > of the LinuxThreads approach. I also think it's better than async > call gates because the application can have explicit control of the > number of LWPs and threads, and the threads library has total control > of scheduling. > > Some basic kernel changes in order to support scheduler activations: [...] Very nice but you're jumping the gun here.. > > Dan Eischen > eischen@vigrid.com > 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.9910311727080.8816-100000>