?? threads-faq.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Linux Threads Home Page</TITLE>
<META NAME="GENERATOR" CONTENT="Mozilla/3.0Gold (X11; I; Linux 2.0.18 i586) [Netscape]">
</HEAD>
<BODY>
<font size=2>Promoting Linux Requires Advertising. It Matters To Me.
<sup>TM</sup></font><br>
<!-- BEGIN LINKEXCHANGE CODE -->
<a href="http://ad.linkexchange.com/3/X322367/gotoad.map"
target="_top">
<img width=440 height=40 border=1 ismap
alt="LinkExchange"
src="http://ad.linkexchange.com/3/X322367/logoshowad?free"></a>
<br>
<font size=1><a href="http://www.linkexchange.com/"
target="_top">LinkExchange Member</a></font><br>
<!-- END LINKEXCHANGE CODE -->
<H1 ALIGN=CENTER>Linux Threads Frequently Asked Questions (FAQ)</H1>
<H3 ALIGN=CENTER>by Sean Walton, KB7rfa</H3>
<H3 ALIGN=CENTER>walton@oclc.org</H3>
<H4 ALIGN=CENTER><FONT SIZE=-1>(Last revised 19 Sep 1996)</FONT></H4>
<b>See also:
<a href="http://pegaso.globenet.it/~ermmau/Threads/">
This mirror in Italy</a> ... may speed your access.
<P><FONT SIZE=+1>Caution</FONT></P>
This FAQ is more than a year out-of-date. POSIX-threads are now a
standard part of most all modern Linux distributions. The new glibc
version 2 (linux libc version 6.0) is fully re-entrant and supports
threads in a fully compliant manner. The default Linux thread
implementation is with kernel-space threads, not user-space threads;
these threads will schedule properly on an SMP architecture.
<p>
You may still find this FAQ useful if you are looking for user-space
threads, DCE threads, a non-standard threads API,
or for threads tools for a language other than C/C++/perl/tcl/scheme,
or if you are upgrading an older system. The "LinuxThreads" package
(below) has become the default package for Linux distributions,
so you will probably want that if upgrading. The MIT (Provenzano)
threads package is popular among some folks.
<p>
Since Sean Walton has moved on to bigger & better things, there is
currently no maintainer for the FAQ. If anyone wants to bring this
FAQ up-to-date, or can offer an otherwise improved and updated FAQ,
please contact me, Linas Vepstas,
<a href="mailto:linas@linas.org">linas@linas.org</a> and I will post
your updates and/or redirect this page to your page.
<P><FONT SIZE=+1>Introduction</FONT></P>
<UL>
<P>This FAQ is designed to answer several frequently asked questions about
Linux threads. For an in-depth view of threads or Linux threads join the
discussions on <A HREF="news://comp.os.linux.development.system">comp.os.linux.development.system
(c.o.l.d.s)</A>.</P>
<P>Since I am only conveying the information (and not an expert), please
direct your specific questions to c.o.l.d.s or comp.programming.threads.
If you have suggestions/additions/revisions to this document, please email
<A HREF="mailto:walton@oclc.org">me</A>.</P>
</UL>
<P><FONT SIZE=+1>Limitations</FONT></P>
<UL>
<P>This is <B>not</B> a discussion on the various implementations of threads:
it is specifically for Linux threading. If you want to see a comparison
between systems or would like to promote some other system than is intended
here, write your own FAQ. Nevertheless, I welcome comments pertinent to
the topic and will gladly add your input.</P>
</UL>
<P><FONT SIZE=+1>Credits</FONT></P>
<UL>
<P>A special thanks to those who significantly helped me put this together:
<A HREF="mailto:byron@cc.gatech.edu">Byron A Jeff</A> (for a lot of theory)
and <A HREF="mailto:slblake@intercenter.net">Steven L. Blake</A> (for his
list of sources).</P>
</UL>
<P>
<HR SIZE=4 WIDTH="100%"></P>
<P>INDEX</P>
<OL>
<LI><A HREF="#ThreadsDefinition">What are threads (user/kernel)?</A></LI>
<LI><A HREF="#CommonProbs">What are the common problems with threads?</A></LI>
<LI><A HREF="#LinuxSupport">Does Linux support threads?</A></LI>
<LI><A HREF="#LinuxLikeOthers">Are Linux threads the same as other implementations?</A></LI>
<LI><A HREF="#KernelReentrant">Is the kernel 100% reentrant?</A></LI>
<LI><A HREF="#ThreadingStdLibs">Do the libraries support multithreading?</A></LI>
<LI><A HREF="#ThreadingHeuristics">What kinds of things should be threaded/multitasked?</A></LI>
<LI><A HREF="#Libs">Are there threading libraries? Where?</A></LI>
<LI><A HREF="#ThreadAccess">How are Linux threads accessed?</A></LI>
<LI><A HREF="#SystemCall">Is there a system call I can use to access kernel
threads?</A></LI>
<LI><A HREF="#ThreadScheduling">Are there ways to determine thread schedule
ordering?</A></LI>
<LI><A HREF="#LanguageSupport">Are there languages that support threads?</A></LI>
<LI><A HREF="#ThreadDebugging">How does one debug threads?</A></LI>
<LI><A HREF="#CloneFlags">What do the individual flags mean and do in clone()?</A></LI>
<LI><A HREF="#ThreadingApps">What applications or libraries currently use
threads?</A></LI>
<LI><A HREF="#LearnMore">Where can I learn more about threads?</A></LI>
</OL>
<P>
<HR></P>
<P><A NAME="ThreadsDefinition"></A><FONT SIZE=+3>What are threads (user/kernel)?</FONT></P>
<UL>
<P>Threads are "light weight processes" (LWPs). The idea is a
process has five fundamental parts: code ("text"), data (VM),
stack, file I/O, and signal tables. "Heavy-weight processes"
(HWPs) have a significant amount of overhead when switching: all the tables
have to be flushed from the processor for each task switch. Also, the only
way to achieve shared information between HWPs is through pipes and "shared
memory". If a HWP spawns a child HWP using fork(), the only part that
is shared is the text.</P>
<P>Threads reduce overhead by sharing fundamental parts. By sharing these
parts, switching happens much more frequently and efficiently. Also, sharing
information is not so "difficult" anymore: everything can be
shared. There are two types of threads: <A HREF="#UserLevel">user-level</A>
and <A HREF="#KernelLevel">kernel-level</A>.</P>
</UL>
<P><A NAME="UserLevel"></A>User-Level Threads</P>
<UL>
<P>User-level avoids the kernel and manages the tables itself. Often this
is called "cooperative multitasking" where the task defines a
set of routines that get "switched to" by manipulating the stack
pointer. Typically each thread "gives-up" the CPU by calling
an explicit switch, sending a signal or doing an operation that involves
the switcher. Also, a timer signal can force switches. User threads typically
can switch faster than kernel threads [however, Linux kernel threads' switching
is actually pretty close in performance].</P>
<P>Disadvantages. User-level threads have a problem that a single thread
can monopolize the timeslice thus starving the other threads within the
task. Also, it has no way of taking advantage of SMPs (Symmetric MultiProcessor
systems, e.g. dual-/quad-Pentiums). Lastly, when a thread becomes I/O blocked,
all other threads within the task lose the timeslice as well.</P>
<P>Solutions/work arounds. Some user-thread libraries have addressed these
problems with several work-arounds. First timeslice monopolization can
be controlled with an external monitor that uses its own clock tick. Second,
some SMPs can support user-level multithreading by firing up tasks on specified
CPUs then starting the threads from there [this form of SMP threading seems
tenuous, at best]. Third, some libraries solve the I/O blocking problem
with special wrappers over system calls, or the task can be written for
nonblocking I/O.</P>
</UL>
<P><A NAME="KernelLevel"></A>Kernel-Level Threads</P>
<UL>
<P>Kernel-level threads often are implemented in the kernel using several
tables (each task gets a table of threads). In this case, the kernel schedules
each thread within the timeslice of each process. There is a little more
overhead with mode switching from user->kernel-> user and loading
of larger contexts, but initial performance measures indicate a negligible
increase in time.</P>
<P>Advantages. Since the clocktick will determine the switching times,
a task is less likely to hog the timeslice from the other threads within
the task. Also I/O blocking is not a problem. Lastly, if properly coded,
the process automatically can take advantage of SMPs and will run incrementally
faster with each added CPU.</P>
</UL>
<P>Combination</P>
<UL>
<P>Some implementations support both user- and kernel-level threads. This
gives the advantages of each to the running task. However, since Linux's
kernel-level threads nearly perform as well as user-level, the only advantage
of using user-threads would be the cooperative multitasking.</P>
</UL>
<P>
<HR></P>
<P><A NAME="CommonProbs"></A><FONT SIZE=+3>What are the common problems
with threads?</FONT></P>
<UL>
<P>Several problems with threads originate from a classic view and its
intrinsic concurrency complexity.</P>
</UL>
<P>Classic View</P>
<UL>
<P>In many other multithreaded OSs, threads are not processes merely parts
of a parent task. Therefore, the question of "what happens if a thread
calls fork() or (worse) if a thread execve()'s some external program"
becomes problematic: the <B>whole task</B> could be replaced. The POSIX
standard defines a thread calling fork() to duplicate only the calling
thread in the new process; and an execve() from a thread would stop all
threads of that process.</P>
<P>Having two different implementations and schedulers for processes is
a flaw that has perpetuated from implementation to implementation. In fact,
some multitasking OSs have opted <B>not</B> to support threads due to these
problems (not to mention the effort needed to make the kernel and libraries
100% reentrant). For example, the POSIX Windows NT appears not to support
threads [author note: it <I>was</I> my understanding that they <I>did</I>
support threads... that's part of Win32NT].</P>
</UL>
<P>Concurrency Complexity</P>
<UL>
<P>Most people have a hard enough time understanding tasks, never mind
"chopped up tasks" or threads. The first problem while programming
is answering the question: "What <I>can</I> be threaded in my app?".
That, in itself, can be very laborious (see section on "<A HREF="#ThreadingHeuristics">What
kinds of things should be threaded/multitasked?</A>").</P>
<P>Another problem is locking. All the nightmares about sharing, locking,
deadlock, race conditions, etc. come vividly alive in threads. Processes
don't usually have to deal with this, since most shared data is passed
through pipes. Now, threads can share file handles, pipes, variables, signals,
etc. Trying to test and duplicate error conditions can cause more gray
hair than a wayward child.</P>
</UL>
<P>
<HR></P>
<P><A NAME="LinuxSupport"></A><FONT SIZE=+3>Does Linux support threads?</FONT></P>
<UL>
<P>Yes. As of 1.3.56, Linux has supported kernel-level multithreading.
There also have been user-level thread libraries around as early as 1.0.9.
</P>
</UL>
<P>
<HR></P>
<P><A NAME="LinuxLikeOthers"></A><FONT SIZE=+3>Are Linux threads the same
as other implementations?</FONT></P>
<UL>
<P>No. They are better -- while mostly keeping the same API. As stated
above, most multithreaded OSs define a thread <B>separately</B> from processes.
Linus Torvalds has defined that a thread is a "context of execution"
(COE). This means that only one process/thread table and one scheduler
is needed.</P>
<P>Traditionally, a thread was just a CPU (and some other minimal state)
state with the process containing the remains (data, stack, I/O, signals).
This would lend itself to very fast switching but would cause basic problems
(e.g. what do "fork()" or "execve()" calls mean when
executed by a thread?).</P>
<P>Consider Linux threads as a superset of this functionality: they still
can switch fast and share process parts, but they can also identify what
parts get shared and have no problems with execve() calls. There are four
flags that determine the level of sharing: </P>
<UL>
<UL>
<P><TT>#define CLONE_VM 0x00000100</TT></P>
<P><TT>#define CLONE_FS 0x00000200</TT></P>
<P><TT>#define CLONE_FILES 0x00000400</TT></P>
<P><TT>#define CLONE_SIGHAND 0x00000800</TT></P>
<P><TT>#define CLONE_PID /* <A HREF="#CloneFlags">not fully implemented</A>
*/</TT></P>
</UL>
</UL>
<P>There has been a lot of talk about "clone()". The system call
(please note: <B><I>low level</I></B>) clone() is an extension to fork().
In fact, clone(0) == fork(). But with the above #define's, any combination
of the VM, filesystem, I/O and signal handlers may be shared.</P>
</UL>
<P>
<HR></P>
<P><A NAME="KernelReentrant"></A><FONT SIZE=+3>Is the kernel 100% reentrant?</FONT></P>
<UL>
<P>No. It's getting there though. As of this date 12-Sep-96, some of the
drivers are still not reentrant. What does this mean? It means that threads
making various system calls will block other threads until the call is
completed. Will it crash? No. When will the fine-threading (not treating
system calls as a single operation) work? That's currently in the works.</P>
</UL>
<P>
<HR></P>
<P><A NAME="ThreadingStdLibs"></A><FONT SIZE=+3>Do the libraries support
multithreading?</FONT></P>
<UL>
<P>No. These are more likely to crash. There are several objects that are
hidden from applications and may be shared inadvertently (e.g. FILE* or
emulated NDP registers). Additionally there are conflicts between some
libraries. For example, SVGAlib & LinuxThreads both use SIGUSR1 and
SIGUSR2 (application-reserved signals). If an app were to use these libraries
together, the app would minimally have problems (or likely crash) and debugging
would be a sequel to "Friday the 13th".</P>
<P>Several individuals are working hard to get the libraries in sync with
this new functionality. The initial work is to provide wrappers around
some of the critical, data-shared functions (e.g. open, close). In fact
some threads libraries have work-arounds for these as well.</P>
<P>Please note that revising the standard libraries is <I>no small task</I>
(gratuitous pun;). If you want to help, contact ----@----.----.</P>
</UL>
<P>
<HR></P>
<P><A NAME="ThreadingHeuristics"></A><FONT SIZE=+3>What kinds of things
should be threaded or multitasked?</FONT></P>
<UL>
<P>If you are a programmer and would like to take advantage of multithreading,
the natural question is what parts of the program should/ should not be
threaded. Here are a few rules of thumb (if you say "yes" to
these, have fun!):</P>
<UL>
<LI>Are there groups of <I>lengthy</I> operations that don't necessarily
depend on other processing (like painting a window, printing a document,
responding to a mouse-click, calculating a spreadsheet column, signal handling,
etc.)?</LI>
<LI>Will there be few locks on data (the amount of shared data is identifiable
and "small")?</LI>
<LI>Are you prepared to worry about locking (mutually excluding data regions
from other threads), deadlocks (a condition where two COEs have locked
data that other is trying to get) and race conditions (a nasty, intractable
problem where data is not locked properly and gets corrupted through threaded
reads & writes)?</LI>
<LI>Could the task be broken into various "responsibilities"?
E.g. Could one thread handle the signals, another handle GUI stuff, etc.?</LI>
</UL>
</UL>
<P>
<HR></P>
<P><A NAME="Libs"></A><FONT SIZE=+3>Are there threading libraries? Where?</FONT></P>
<UL>
<P>Yes, there are several. Here are a several URLs Steven Blake (2-Aug-1996)
has compiled for our use. Please note that I have emailed the authors (if
known) to get more information about their libraries.</P>
</UL>
<CENTER><P><FONT SIZE=+3>Linux Threads Packages</FONT></P></CENTER>
<TABLE BORDER=1 CELLSPACING=2 CELLPADDING=5 WIDTH="100%" >
<TR>
<TD ALIGN=RIGHT><FONT SIZE=+2>Title:</FONT></TD>
<TD><FONT SIZE=+2>Bare-Bones Threads</FONT></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Author:</TD>
<TD><A HREF="mailto:neufeld@physics.utoronto.ca">Christopher Neufeld</A></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Repositories:</TD>
<TD>[Documentation] <A HREF="ftp://caliban.physics.utoronto.ca/pub/linux/bb_threads.tar.gz">[Source]</A></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>API:</TD>
<TD>Non-standard</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Description:</TD>
<TD>This is a very basic, bare-bones threading package which has been tested
on both single-CPU and SMP Linux boxes.</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>License: </TD>
<TD>GPL(? Source is included)</TD>
</TR>
</TABLE>
<TABLE BORDER=1 CELLSPACING=2 CELLPADDING=5 WIDTH="100%" >
<TR>
<TD ALIGN=RIGHT><FONT SIZE=+2>Title:</FONT></TD>
<TD><A NAME="DCEthreads"></A><FONT SIZE=+2>DCEthreads</FONT></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Author:</TD>
<TD><A HREF="mailto:mtp@big.aa.net">Michael T. Peterson</A></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Repositories:</TD>
<TD><A HREF="http://www.aa.net/~mtp/PCthreads.html">[Documentation]</A>
<A HREF="ftp://sunsite.unc.edu/pub/Linux/devel/lang/c/dcethreads-1.0.tar.gz">[Source]</A></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>API:</TD>
<TD>POSIX 1003.4c Draft 4 (?)</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Description:</TD>
<TD>PCthreads (tm) is a multithreading library for Linux-based Intel systems
and is based on the POSIX 1003.1c standard. The kit contains the sources
for the library (libpthreads), a build environment for building both ELF
and A.OUT versions of the library, and a complete set of man pages for
all POSIX .1c functions.</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>License: </TD>
<TD>GPL(? Source is included)</TD>
</TR>
</TABLE>
<TABLE BORDER=1 CELLSPACING=2 CELLPADDING=5 WIDTH="100%" >
<TR>
<TD ALIGN=RIGHT><FONT SIZE=+2>Title:</FONT></TD>
<TD><FONT SIZE=+2>FSU Pthreads</FONT></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Author:</TD>
<TD><A HREF="mailto:mueller@informatik.hu-berlin.de">Frank Mueller</A></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Repositories:</TD>
<TD><A HREF="http://www.informatik.hu-berlin.de/~mueller/projects.html">[Documentation]</A>
<A HREF="http://www.cs.fsu.edu/~mueller/projects.html">[Documentation mirror]</A>
<A HREF="http://www.informatik.hu-berlin.de/~mueller/ftp/pub/PART/pthreads.tar.gz">[Source]
</A><A HREF="ftp://ftp.cs.fsu.edu/pub/PART/PTHREADS/pthreads.tar.gz">[Source
mirror]</A> </TD>
</TR>
<TR>
<TD ALIGN=RIGHT>API:</TD>
<TD>POSIX 1003.1c</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Description:</TD>
<TD>Pthreads is a C library which implements POSIX threads for SunOS 4.1.x,
Solaris 2.x, SCO UNIX, FreeBSD and Linux. Used for GNU Ada Runtime; partial
libc support.</TD>
</TR>
<TR>
<TD ALIGN=RIGHT>License: </TD>
<TD>Gnu Public Library License</TD>
</TR>
</TABLE>
<TABLE BORDER=1 CELLSPACING=2 CELLPADDING=5 WIDTH="100%" >
<TR>
<TD ALIGN=RIGHT><FONT SIZE=+2>Title:</FONT></TD>
<TD><FONT SIZE=+2>JKthread</FONT></TD>
</TR>
<TR>
<TD ALIGN=RIGHT>Author:</TD>
<TD><A HREF="mailto:jeffk@awinc.com">Jeff Koftinoff</A></TD>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -