📄 faq.html
字号:
<HTML><HEAD><TITLE>LinuxThreads Frequently Asked Questions</TITLE></HEAD><BODY><H1 ALIGN=center>LinuxThreads Frequently Asked Questions <BR> (with answers)</H1><HR><P><A HREF="#A">A. The big picture</A><BR><A HREF="#B">B. Getting more information</A><BR><A HREF="#C">C. Issues related to the C library</A><BR><A HREF="#D">D. Problems, weird behaviors, potential bugs</A><BR><A HREF="#E">E. Missing functions, wrong types, etc</A><BR><A HREF="#F">F. C++ issues</A><BR><A HREF="#G">G. Debugging LinuxThreads programs</A><BR><A HREF="#H">H. Compiling multithreaded code; errno madness</A><BR><A HREF="#I">I. X-Windows and other libraries</A><BR><A HREF="#J">J. Signals and threads</A><BR><A HREF="#K">K. Internals of LinuxThreads</A><P><HR><P><H2><A NAME="A">A. The big picture</A></H2><H4><A NAME="A.1">A.1: What is LinuxThreads?</A></H4>LinuxThreads is a Linux library for multi-threaded programming.It implements the Posix 1003.1c API (Application ProgrammingInterface) for threads. It runs on any Linux system with kernel 2.0.0or more recent, and a suitable C library (see section <A HREF="B">B</A>).<P><H4><A NAME="A.2">A.2: What are threads?</A></H4>A thread is a sequential flow of control through a program.Multi-threaded programming is, thus, a form of parallel programmingwhere several threads of control are executing concurrently in theprogram. All threads execute in the same memory space, and cantherefore work concurrently on shared data.<P>Multi-threaded programming differs from Unix-style multi-processing inthat all threads share the same memory space (and a few other systemresources, such as file descriptors), instead of running in their ownmemory space as is the case with Unix processes.<P>Threads are useful for two reasons. First, they allow a program toexploit multi-processor machines: the threads can run in parallel onseveral processors, allowing a single program to divide its workbetween several processors, thus running faster than a single-threadedprogram, which runs on only one processor at a time. Second, someprograms are best expressed as several threads of control thatcommunicate together, rather than as one big monolithic sequentialprogram. Examples include server programs, overlapping asynchronousI/O, and graphical user interfaces.<P><H4><A NAME="A.3">A.3: What is POSIX 1003.1c?</A></H4>It's an API for multi-threaded programming standardized by IEEE aspart of the POSIX standards. Most Unix vendors have endorsed thePOSIX 1003.1c standard. Implementations of the 1003.1c API arealready available under Sun Solaris 2.5, Digital Unix 4.0, Silicon Graphics IRIX 6, and should soon be available from othervendors such as IBM and HP. More generally, the 1003.1c API isreplacing relatively quickly the proprietary threads library that weredeveloped previously under Unix, such as Mach cthreads, Solaristhreads, and IRIX sprocs. Thus, multithreaded programs using the1003.1c API are likely to run unchanged on a wide variety of Unixplatforms.<P><H4><A NAME="A.4">A.4: What is the status of LinuxThreads?</A></H4>In short, it's not completely finished (hence the version numbers in0.<I>x</I>), but what is done is pretty mature.LinuxThreads implements almost all of Posix 1003.1c, as well as a fewextensions. The only part of LinuxThreads that does not conform yetto Posix is signal handling (see section <A HREF="#J">J</A>). Apartfrom the signal stuff, all the Posix 1003.1c base functionality isprovided and conforms to the standard (to the best of my knowledge).The signal stuff is hard to get right, at least without special kernelsupport, and while I'm definitely looking at ways to implement thePosix behavior for signals, this might take a long time before it'scompleted.<P><H4><A NAME="A.5">A.5: How stable is LinuxThreads?</A></H4>The basic functionality (thread creation and termination, mutexes,conditions, semaphores) is very stable. Several industrial-strengthprograms, such as the AOL multithreaded Web server, use LinuxThreadsand seem quite happy about it. There are some rough edges inthe LinuxThreads / C library interface, at least with libc 5, but mostof these rough edges are fixed in glibc 2, which should soon becomethe standard C library for Linux distributions (see section <AHREF="#C">C</A>). <P><HR><P><H2><A NAME="B">B. Getting more information</A></H2><H4><A NAME="B.1">B.1: What are good books and other sources ofinformation on POSIX threads?</A></H4>The FAQ for comp.programming.threads lists several books:<A HREF="http://www.serpentine.com/~bos/threads-faq/">http://www.serpentine.com/~bos/threads-faq/</A>.<P>There are also some online tutorials. Follow the links from theLinuxThreads web page:<A HREF="http://pauillac.inria.fr/~xleroy/linuxthreads">http://pauillac.inria.fr/~xleroy/linuxthreads</A>.<P><H4><A NAME="B.2">B.2: I'd like to be informed of future developments onLinuxThreads. Is there a mailing list for this purpose?</A></H4>I post LinuxThreads-related announcements on the newsgroup<A HREF="news:comp.os.linux.announce">comp.os.linux.announce</A>,and also on the mailing list<code>linux-threads@magenet.com</code>.You can subscribe to the latter by writing<A HREF="mailto:majordomo@magenet.com">majordomo@magenet.com</A>.<P><H4><A NAME="B.3">B.3: What are good places for discussingLinuxThreads?</A></H4>For questions about programming with POSIX threads in general, usethe newsgroup<A HREF="news:comp.programming.threads">comp.programming.threads</A>.Be sure you read the<A HREF="http://www.serpentine.com/~bos/threads-faq/">FAQ</A>for this group before you post.<P>For Linux-specific questions, use<AHREF="news:comp.os.linux.development.apps">comp.os.linux.development.apps</A>and <AHREF="news:comp.os.linux.development.kernel">comp.os.linux.development.kernel</A>.The latter is especially appropriate for questions relative to theinterface between the kernel and LinuxThreads.<P>Very specific LinuxThreads questions, and in particular everythingthat looks like a potential bug in LinuxThreads, should be maileddirectly to me (<code>Xavier.Leroy@inria.fr</code>). Before mailingme, make sure that your question is not answered in this FAQ.<P><H4><A NAME="B.4">B.4: I'd like to read the POSIX 1003.1c standard. Isit available online?</A></H4>Unfortunately, no. POSIX standards are copyrighted by IEEE, andIEEE does not distribute them freely. You can buy paper copies fromIEEE, but the price is fairly high ($120 or so). If you disagree withthis policy and you're an IEEE member, be sure to let them know.<P>On the other hand, you probably don't want to read the standard. It'svery hard to read, written in standard-ese, and targeted toimplementors who already know threads inside-out. A good book onPOSIX threads provides the same information in a much more readable form.I can personally recommend Dave Butenhof's book, <CITE>Programmingwith POSIX threads</CITE> (Addison-Wesley). Butenhof was part of thePOSIX committee and also designed the Digital Unix implementations ofPOSIX threads, and it shows.<P>Another good source of information is the Open Group Single Unixspecification (Unix 98) which is available both<A HREF="http://www.UNIX-systems.org/online.html">on-line</A>and as a<A HREF="http://www.UNIX-systems.org/gosolo2/">book and CD/ROM</A>.That specification includes pretty much all the POSIX standards,with some extensions and clarifications.<P><HR><P><H2><A NAME="C">C. Issues related to the C library</A></H2><H4><A NAME="C.1">C.1: Which version of the C library should I usewith LinuxThreads?</A></H4>Most current Linux distributions come with libc version 5, maintainedby H.J.Lu. For LinuxThreads to work properly, you must use eitherlibc 5.2.18 or libc 5.4.12 or later. Avoid 5.3.12 and 5.4.7: thesehave problems with the per-thread errno variable.<P>Unfortunately, many popular Linux distributions (e.g. RedHat 4.2) comewith libc 5.3.12 preinstalled -- the one that does not work withLinuxThreads. Fortunately, you can often find pre-packaged binariesof more recent versions of libc for these distributions. In the caseof RedHat 4, there is a RPM package for libc-5.4 in the "contrib"area of RedHat FTP sites.<P><H4><A NAME="C.2">C.2: What about glibc 2, a.k.a. libc 6?</A></H4>It's the next generation libc for Linux, developed by UlrichDrepper and other FSF collaborators. glibc 2 offers much bettersupport for threads than libc 5. Indeed, thread support wasplanned from the very early stages of glibc 2, while it's alast-minute addition to libc 5. glibc 2 actually comes with aspecially adapted version of LinuxThreads, which you can drop in theglibc 2 sources as an add-on package.<H4><A NAME="C.3">C.3: So, should I switch to glibc 2, or stay with arecent libc 5?</A></H4>Depends how you plan to do it. Switching an already installedsystem from libc 5 to glibc 2 is not completely straightforward.See the <A HREF="http://sunsite.unc.edu/LDP/HOWTO/Glibc2-HOWTO.html">Glibc2HOWTO</A> for more information.But (re-)installing a Linux distribution based on glibc 2 is easy.One such distribution available now is RedHat 5.0. Debian and other Linux distributors will also provide glibc 2-based distributions in thenear future.<P><H4><A NAME="C.4">C.4: Where can I find glibc 2 and the version of LinuxThreads that goes with it?</A></H4>On <code>prep.ai.mit.edu</code> and its many, many mirrors around the world.See <AHREF="http://www.gnu.org/order/ftp.html">http://www.gnu.org/order/ftp.html</A>for a list of mirrors.<P><HR><P><H2><A NAME="D">D. Problems, weird behaviors, potential bugs</A></H2><H4><A NAME="D.1">D.1: When I compile LinuxThreads, I run into problems infile <code>libc_r/dirent.c</code></A></H4>You probably mean:<PRE> libc_r/dirent.c:94: structure has no member named `dd_lock'</PRE>I haven't actually seen this problem, but several users reported it.My understanding is that something is wrong in the include files ofyour Linux installation (<code>/usr/include/*</code>). Make sureyou're using a supported version of the C library. (See section <AHREF="#B">B</A>).<P><H4><A NAME="D.2">D.2: When I compile LinuxThreads, I run into problems with<CODE>/usr/include/sched.h</CODE>: there are several occurrences of<CODE>_p</CODE> that the C compiler does not understand</A></H4>Yes, <CODE>/usr/include/sched.h</CODE> that comes with libc 5.3.12 is broken.Replace it with the <code>sched.h</code> file contained in theLinuxThreads distribution. But really you should not be using libc5.3.12 with LinuxThreads! (See question <A HREF="#C.1">C.1</A>.)<P><H4><A NAME="D.3">D.3: My program does <CODE>fdopen()</CODE> on a filedescriptor opened on a pipe. When I link it with LinuxThreads,<CODE>fdopen()</CODE> always returns NULL!</A></H4>You're using one of the buggy versions of libc (5.3.12, 5.4.7., etc).See question <A HREF="#C.1">C.1</A> above.<P><H4><A NAME="D.4">D.4: My program crashes the first time it calls<CODE>pthread_create()</CODE> !</A></H4>You wouldn't be using glibc 2.0, by any chance? That's a known bugwith glibc 2.0. Please upgrade to 2.0.1 or later.<P><H4><A NAME="D.5">D.5: When I'm running a program that creates Nthreads, <code>top</code> or <code>ps</code> display N+2 processes that are running my program. What do all theseprocesses correspond to?</A></H4>Due to the general "one process per thread" model, there's one processfor the initial thread and N processes for the threads it createdusing <CODE>pthread_create</CODE>. That leaves one processunaccounted for. That extra process corresponds to the "threadmanager" thread, a thread created internally by LinuxThreads to handlethread creation and thread termination. This extra thread is asleepmost of the time.<H4><A NAME="D.6">D.6: Scheduling seems to be very unfair when thereis strong contention on a mutex: instead of giving the mutex to eachthread in turn, it seems that it's almost always the same thread thatgets the mutex. Isn't this completely broken behavior?</A></H4>What happens is the following: when a thread unlocks a mutex, allother threads that were waiting on the mutex are sent a signal whichmakes them runnable. However, the kernel scheduler may or may notrestart them immediately. If the thread that unlocked the mutextries to lock it again immediately afterwards, it is likely that itwill succeed, because the threads haven't yet restarted. This resultsin an apparently very unfair behavior, when the same thread repeatedlylocks and unlocks the mutex, while other threads can't lock the mutex.<P>This is perfectly acceptable behavior with respect to the POSIXstandard: for the default scheduling policy, POSIX makes no guaranteesof fairness, such as "the thread waiting for the mutex for the longesttime always acquires it first". This allows implementations ofmutexes to remain simple and efficient. Properly writtenmultithreaded code avoids that kind of heavy contention on mutexes,and does not run into fairness problems. If you need schedulingguarantees, you should consider using the real-time schedulingpolicies <code>SCHED_RR</code> and <code>SCHED_FIFO</code>, which haveprecisely defined scheduling behaviors. <P><H4><A NAME="D.7">D.7: I have a simple test program with two threadsthat do nothing but <CODE>printf()</CODE> in tight loops, and from theprintout it seems that only one thread is running, the other doesn'tprint anything!</A></H4>If you wait long enough, you should see the second thread kick in.But still, you're right, one thread prevents the other one fromrunning for long periods of time. The reason is explained inquestion <A HREF="#D.6">D.6</A> above: <CODE>printf()</CODE> performslocking on <CODE>stdout</CODE>, and thus your two threads contend veryheavily for the mutex associated with <CODE>stdout</CODE>. But if youdo some real work between two calls to <CODE>printf()</CODE>, you'llsee that scheduling becomes much smoother. <P><H4><A NAME="D.8">D.8: I've looked at <code><pthread.h></code>and there seems to be a gross error in the <code>pthread_cleanup_push</code>macro: it opens a block with <code>{</code> but does not close it!Surely you forgot a <code>}</code> at the end of the macro, right?</A></H4>Nope. That's the way it should be. The closing brace is provided bythe <code>pthread_cleanup_pop</code> macro. The POSIX standardrequires <code>pthread_cleanup_push</code> and<code>pthread_cleanup_pop</code> to be used in matching pairs, at thesame level of brace nesting. This allows<code>pthread_cleanup_push</code> to open a block in order tostack-allocate some data structure, and<code>pthread_cleanup_pop</code> to close that block. It's ugly, but⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -