Date: Sun, 31 Oct 1999 18:44:02 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: freebsd-arch@freebsd.org, julian@whistle.com Subject: Re: Threads models and FreeBSD. Message-ID: <199910312344.SAA24146@pcnet1.pcnet.com>
next 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.
>
> 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.
11.) Ability for the threads library to cancel/terminate a thread
blocked in the kernel.
12.) A libpthread that can be linked with libc.
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.
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 ;)
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:
o Modify the sleep queue to queue wait_node entities, not procs.
A wait_node would consist of at least a boolean flag and a proc
or thread pointer to support queueing of threads or procs.
o Modify mi_switch to call mi_context_switch for a multi-threaded
process. When a process blocks in the kernel, mi_context_switch
saves the user and kernel context, switches to a predetermined
kernel/user context and makes an upcall to the threads library
notifying it of the event. The library returns with another
thread to run.
o Allow for maintaining (off proc) a queue of kernel contexts (at
least one for each blocked thread, one for each currently running
thread, and one for the upcall notification). The kernel context
would consist of at least a kernel stack, kernel register set
save area, and a pointer to the user-land ucontext/thread.
You would also hang the list of LWPs off the parent proc, and
be able to determine which LWPs are being used or not used.
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?199910312344.SAA24146>