Date: Tue, 30 Nov 1999 11:54:31 -0500 From: "Allen Pulsifer" <pulsifer@mediaone.net> To: <freebsd-arch@freebsd.org> Subject: RE: Revisitted.. Threads goals.? Message-ID: <NBBBJNDFEKPEHPFCLNLHGEIJEJAA.pulsifer@mediaone.net> In-Reply-To: <Pine.BSF.4.10.9911292207120.7902-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Please forgive me for sticking my foot into this conversation.
I'm new to FreeBSD and have only been following this conversation
for a week. I don't pretend to know a lot of the theory, or even
how threads and SMP are currently implremented in FreeBSD.
Everything I could possibly add to this discussion is probably
already assumed and well understood by the people on this list,
but sometimes it helps to restate the obvious. If not, please
feel free to hit the delete key.
To step back even further from what Julian just said, the
purpose of implementing threads is to have a resource-
efficient method of multitasking.
Unix operating systems traditionally use processes to implement
multitasking. The process structure provides for system
security (via separate, virtual address spaces), fair
sharing of resources (via round robin scheduling) and
efficient use of resources (via blocking and task switching).
However, the implementation of processes makes them resource
intensive. They are expensive to create, take a lot of memory,
expensive to manage (switch from one to another) and can only
communicate with each other primarily though expensive methods
such as IPC. [Have I left anything out?]
The purpose of threads is to provide a more efficient method
of multitasking. The goals of threads are to:
1) minimize the amount of memory that each thread uses,
so that many (thousands?) of threads can be created;
2) minimize the amount of work that must be done to
switch between treads (both scheduling work and
actual task switching);
3) allow threads to efficiently communicate with each other;
4) perform all of the above while still providing system
security, and fair and efficient use of resources.
To meet these goals, it seems obvious that process structure
would be maintained. This allows system security to be
maintained, and may also allow fair use of resources to
be maintained. (The latter is what Julian is arguing for.)
It would also seem obvious that threads must share the
same address space. This allows efficient communication
between threads, as well as efficient task switching
between two threads that share the same address space.
(But of course, it doesn't help threads with
separate address spaces, and this has implications
for optimal thead scheduling.)
Given the above, it would finally seem obvious that
threads sharing the same address space would live within
the same process, and possibly inherit all the rest
of the baggage that comes along with that (PID, etc).
Part of the discussion that is going on seems to be
simply about what things do threads share and what
things do they not share. For example, each thread
must have its own CPU state (PC, registers, etc)
and thread (or user) stack so that it can be executed
and suspended as needed. However, all threads associated
with a process share the same memory map. Other items
may be shared or not shared depending on what
you are trying to accomplish. A lot of the decisions
are tradeoffs between functionality and efficiency.
For example, it would seem desirable to make the
unshared structures as small as possible, to
minimize memory use; however, that may sacrifice
functionality. I am not familiar with all of the
structures involved, but maybe someone would make
a list: what structures must absolutely be
unshared, and what structures can optionally be made
unique, and what features or functionality are gained
by making them unique? A list like this would assist
in the tradeoff analysis and decision making.
Implementation details aside, it seems to me that one
of the major points Matt Dillion is looking for is
the ability for two threads, bound to the same
process, to run simultaneously on two different
CPU's. This seems to be a very desirable goal,
however, the question seems to be, what is the cost
of implementing this in terms of complexity and level
of effort?
Furthermore, while this feature would seem to be desireable,
if it were NOT implemented, there maybe some assumptions
that could be made by user programs and shared libraries
that would make the use of the system less complex and
more efficient. For example, if it is guaranteed that
two threads bound to a process cannot be executing
simultaneously, does that simplify user programming?
In addition, if it is guaranteed that a thread will
not surrender the CPU to another thread in its same
process except at certain well defined times
(a voluntary surrender, a system call, a signal)
does that simplify user programming even more?
Do these gains in simplicity make it worthwile
not implementing what might otherwise be a
powerful feature?
Finally, Matt seems to making some points about how the
kernel itself can make use of threads. I admit I don't
have the background to understand what he is saying.
But aside from having "user" threads run in both
user and kernel mode, is it envisioned that the
kernel itself will have threads that aren't bound
to any user process? Where will those threads
be used and how will they be managed? Regardless
of whether two "user" or process threads can run
simultaneously on two seprate CPU's, it would still
seem desireable to allow two purely kernel threads
to do this.
I know everyone who is active on this list is ten times more
knowledgeble and experienced than I am, but I hope some of
these thoughts (none of which haven't been said somewhere
before) might be helpful.
Allen
> -----Original Message-----
> From: owner-freebsd-arch@FreeBSD.ORG
> [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of Julian Elischer
> Sent: Tuesday, November 30, 1999 1:45 AM
> To: freebsd-arch@FreeBSD.ORG
> Subject: Revisitted.. Threads goals.?
>
>
>
> I think this is a good time for us to re-examine some of the things that
> we decided were goals.
>
> I have somme comments I'd like to make AT THE END, but after the general
> neuron frying of the last week or so it might be a good idea to look at
> these again and see if any of them have changed in light of the
> discussion. I have difficulty in seeing this list as exhaustive or
> correct. We need someone who is very into threads to contribute.
> Jason? What do yuo see as YOUR goals?
>
>
> -----last version of the goals I have in my mailbox.----
>
> 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,
> and have min(M,N) threads simultaneously executing.
> 2A/ ability to tune and control the above..
>
> 3/ Just because one thread blocks, doesn't mean that
> the others can't keep running.
>
> 4/ All threads in a processs see the same address space (exactly).
> 4A/ All threads in a process share the same system resources, except cpu
> which is treated specially, and some as yet unspecified thread
> specific uniqifier.
>
> 5/ A process may be able to group threads into classes that have
> different system priorities. These classes can not have priorities
> greater than the process itself or a child could achieve, and should
> be treatable by the system as a separate child process from a
> scheduling point of view (including limits).
> 5A/ As a result threaded processes should have no more capability to
> swamp a system than a regular forking process.
>
> 6/ Some well documeted scheme exists for handling signals and other
> async events.
>
> 7/ Exit/shutdown protocol is well defined.
>
> 8/ The allocation of user level threads to thread groups is opaque to the
> kernel.
>
> 9/ Quick access to curthread and thread specific data.
>
> 10/ A method to ask a thread blocked in the kernel to wake up and back
> out (similar to present 'signals'). (see 6, 7)
>
>
> ---- possible userland implementation goals-----
>
> 1/ A libpthread that can be linked with libc.
>
> 2/ Libc needs to change so that library functions and system calls
> used internal to the library do not use the externally visible
> cancellable equivalents.
> 3/ see 8 above.
>
> -------------
> Meta-goals
> -------------
> We should keep our eyes on:
> *) scalability
> *) performance
> *) ability to support features required by standards based threads.
> *) ability to support features of those thread packages we select as
> needed.
> ---------------------------
> COMMENTS:
>
> Peter made a valid point which is that maybe we should figure out
> a waypoint between here and there, that gives us a working but
> sub-optimal threads package of the order of the linux threads package,
> that can be included in 4.0
>
> We may have 2 whole months to get that done :-(
>
>
> Also, Matt Dillon has been arguing strongly that point 8 (kernel)
> and point 3(user) are non goals, in fact he wants the opposite.
> He also argues that making an entity that groups KSE's on a scale smaller
> than the entire process is a bad idea. I disagree but we haven't
> decided anyting yet. He claims 'simplicity. I think that he may be sliding
> back up teh other side of th ecurve by trying to simplify more than the
> goals (many of which we are inherritting from Posix via the 3rd meta-goal)
> allow.
>
> how would we move towards Peter's hope? and are there things we can do
> that there is no argument about? I think that separating the proc
> structure is agreed, but it is not needed for Linux threads..
>
>
>
>
>
>
> 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?NBBBJNDFEKPEHPFCLNLHGEIJEJAA.pulsifer>