3 <TITLE>LinuxThreads Frequently Asked Questions</TITLE>
6 <H1 ALIGN=center>LinuxThreads Frequently Asked Questions <BR>
8 <H2 ALIGN=center>[For LinuxThreads version 0.8]</H2>
12 <A HREF="#A">A. The big picture</A><BR>
13 <A HREF="#B">B. Getting more information</A><BR>
14 <A HREF="#C">C. Issues related to the C library</A><BR>
15 <A HREF="#D">D. Problems, weird behaviors, potential bugs</A><BR>
16 <A HREF="#E">E. Missing functions, wrong types, etc</A><BR>
17 <A HREF="#F">F. C++ issues</A><BR>
18 <A HREF="#G">G. Debugging LinuxThreads programs</A><BR>
19 <A HREF="#H">H. Compiling multithreaded code; errno madness</A><BR>
20 <A HREF="#I">I. X-Windows and other libraries</A><BR>
21 <A HREF="#J">J. Signals and threads</A><BR>
22 <A HREF="#K">K. Internals of LinuxThreads</A><P>
27 <H2><A NAME="A">A. The big picture</A></H2>
29 <H4><A NAME="A.1">A.1: What is LinuxThreads?</A></H4>
31 LinuxThreads is a Linux library for multi-threaded programming.
32 It implements the Posix 1003.1c API (Application Programming
33 Interface) for threads. It runs on any Linux system with kernel 2.0.0
34 or more recent, and a suitable C library (see section <A HREF="C">C</A>).
37 <H4><A NAME="A.2">A.2: What are threads?</A></H4>
39 A thread is a sequential flow of control through a program.
40 Multi-threaded programming is, thus, a form of parallel programming
41 where several threads of control are executing concurrently in the
42 program. All threads execute in the same memory space, and can
43 therefore work concurrently on shared data.<P>
45 Multi-threaded programming differs from Unix-style multi-processing in
46 that all threads share the same memory space (and a few other system
47 resources, such as file descriptors), instead of running in their own
48 memory space as is the case with Unix processes.<P>
50 Threads are useful for two reasons. First, they allow a program to
51 exploit multi-processor machines: the threads can run in parallel on
52 several processors, allowing a single program to divide its work
53 between several processors, thus running faster than a single-threaded
54 program, which runs on only one processor at a time. Second, some
55 programs are best expressed as several threads of control that
56 communicate together, rather than as one big monolithic sequential
57 program. Examples include server programs, overlapping asynchronous
58 I/O, and graphical user interfaces.<P>
60 <H4><A NAME="A.3">A.3: What is POSIX 1003.1c?</A></H4>
62 It's an API for multi-threaded programming standardized by IEEE as
63 part of the POSIX standards. Most Unix vendors have endorsed the
64 POSIX 1003.1c standard. Implementations of the 1003.1c API are
65 already available under Sun Solaris 2.5, Digital Unix 4.0,
66 Silicon Graphics IRIX 6, and should soon be available from other
67 vendors such as IBM and HP. More generally, the 1003.1c API is
68 replacing relatively quickly the proprietary threads library that were
69 developed previously under Unix, such as Mach cthreads, Solaris
70 threads, and IRIX sprocs. Thus, multithreaded programs using the
71 1003.1c API are likely to run unchanged on a wide variety of Unix
74 <H4><A NAME="A.4">A.4: What is the status of LinuxThreads?</A></H4>
76 LinuxThreads implements almost all of Posix 1003.1c, as well as a few
77 extensions. The only part of LinuxThreads that does not conform yet
78 to Posix is signal handling (see section <A HREF="#J">J</A>). Apart
79 from the signal stuff, all the Posix 1003.1c base functionality,
80 as well as a number of optional extensions, are provided and conform
81 to the standard (to the best of my knowledge).
82 The signal stuff is hard to get right, at least without special kernel
83 support, and while I'm definitely looking at ways to implement the
84 Posix behavior for signals, this might take a long time before it's
87 <H4><A NAME="A.5">A.5: How stable is LinuxThreads?</A></H4>
89 The basic functionality (thread creation and termination, mutexes,
90 conditions, semaphores) is very stable. Several industrial-strength
91 programs, such as the AOL multithreaded Web server, use LinuxThreads
92 and seem quite happy about it. There used to be some rough edges in
93 the LinuxThreads / C library interface with libc 5, but glibc 2
94 fixes all of those problems and is now the standard C library on major
95 Linux distributions (see section <A HREF="#C">C</A>). <P>
100 <H2><A NAME="B">B. Getting more information</A></H2>
102 <H4><A NAME="B.1">B.1: What are good books and other sources of
103 information on POSIX threads?</A></H4>
105 The FAQ for comp.programming.threads lists several books:
106 <A HREF="http://www.serpentine.com/~bos/threads-faq/">http://www.serpentine.com/~bos/threads-faq/</A>.<P>
108 There are also some online tutorials. Follow the links from the
109 LinuxThreads web page:
110 <A HREF="http://pauillac.inria.fr/~xleroy/linuxthreads">http://pauillac.inria.fr/~xleroy/linuxthreads</A>.<P>
112 <H4><A NAME="B.2">B.2: I'd like to be informed of future developments on
113 LinuxThreads. Is there a mailing list for this purpose?</A></H4>
115 I post LinuxThreads-related announcements on the newsgroup
116 <A HREF="news:comp.os.linux.announce">comp.os.linux.announce</A>,
117 and also on the mailing list
118 <code>linux-threads@magenet.com</code>.
119 You can subscribe to the latter by writing
120 <A HREF="mailto:majordomo@magenet.com">majordomo@magenet.com</A>.<P>
122 <H4><A NAME="B.3">B.3: What are good places for discussing
123 LinuxThreads?</A></H4>
125 For questions about programming with POSIX threads in general, use
127 <A HREF="news:comp.programming.threads">comp.programming.threads</A>.
129 <A HREF="http://www.serpentine.com/~bos/threads-faq/">FAQ</A>
130 for this group before you post.<P>
132 For Linux-specific questions, use
134 HREF="news:comp.os.linux.development.apps">comp.os.linux.development.apps</A>
136 HREF="news:comp.os.linux.development.kernel">comp.os.linux.development.kernel</A>.
137 The latter is especially appropriate for questions relative to the
138 interface between the kernel and LinuxThreads.<P>
140 <H4><A NAME="B.4">B.4: How should I report a possible bug in
141 LinuxThreads?</A></H4>
143 If you're using glibc 2, the best way by far is to use the
144 <code>glibcbug</code> script to mail a bug report to the glibc
147 If you're using an older libc, or don't have the <code>glibcbug</code>
148 script on your machine, then e-mail me directly
149 (<code>Xavier.Leroy@inria.fr</code>). <P>
151 In both cases, before sending the bug report, make sure that it is not
152 addressed already in this FAQ. Also, try to send a short program that
153 reproduces the weird behavior you observed. <P>
155 <H4><A NAME="B.5">B.5: I'd like to read the POSIX 1003.1c standard. Is
156 it available online?</A></H4>
158 Unfortunately, no. POSIX standards are copyrighted by IEEE, and
159 IEEE does not distribute them freely. You can buy paper copies from
160 IEEE, but the price is fairly high ($120 or so). If you disagree with
161 this policy and you're an IEEE member, be sure to let them know.<P>
163 On the other hand, you probably don't want to read the standard. It's
164 very hard to read, written in standard-ese, and targeted to
165 implementors who already know threads inside-out. A good book on
166 POSIX threads provides the same information in a much more readable form.
167 I can personally recommend Dave Butenhof's book, <CITE>Programming
168 with POSIX threads</CITE> (Addison-Wesley). Butenhof was part of the
169 POSIX committee and also designed the Digital Unix implementations of
170 POSIX threads, and it shows.<P>
172 Another good source of information is the X/Open Group Single Unix
173 specification which is available both
174 <A HREF="http://www.rdg.opengroup.org/onlinepubs/7908799/index.html">on-line</A>
176 <A HREF="http://www.UNIX-systems.org/gosolo2/">book and CD/ROM</A>.
177 That specification includes pretty much all the POSIX standards,
178 including 1003.1c, with some extensions and clarifications.<P>
183 <H2><A NAME="C">C. Issues related to the C library</A></H2>
185 <H4><A NAME="C.1">C.1: Which version of the C library should I use
186 with LinuxThreads?</A></H4>
188 The best choice by far is glibc 2, a.k.a. libc 6. It offers very good
189 support for multi-threading, and LinuxThreads has been closely
190 integrated with glibc 2. The glibc 2 distribution contains the
191 sources of a specially adapted version of LinuxThreads.<P>
193 glibc 2 comes preinstalled as the default C library on several Linux
194 distributions, such as RedHat 5 and up, and Debian 2.
195 Those distributions include the version of LinuxThreads matching
198 <H4><A NAME="C.2">C.2: My system has libc 5 preinstalled, not glibc
199 2. Can I still use LinuxThreads?</H4>
201 Yes, but you're likely to run into some problems, as libc 5 only
202 offers minimal support for threads and contains some bugs that affect
203 multithreaded programs. <P>
205 The versions of libc 5 that work best with LinuxThreads are
206 libc 5.2.18 on the one hand, and libc 5.4.12 or later on the other hand.
207 Avoid 5.3.12 and 5.4.7: these have problems with the per-thread errno
210 <H4><A NAME="C.3">C.3: So, should I switch to glibc 2, or stay with a
211 recent libc 5?</A></H4>
213 I'd recommend you switch to glibc 2. Even for single-threaded
214 programs, glibc 2 is more solid and more standard-conformant than libc
215 5. And the shortcomings of libc 5 almost preclude any serious
216 multi-threaded programming.<P>
218 Switching an already installed
219 system from libc 5 to glibc 2 is not completely straightforward.
220 See the <A HREF="http://sunsite.unc.edu/LDP/HOWTO/Glibc2-HOWTO.html">Glibc2
221 HOWTO</A> for more information. Much easier is (re-)installing a
222 Linux distribution based on glibc 2, such as RedHat 6.<P>
224 <H4><A NAME="C.4">C.4: Where can I find glibc 2 and the version of
225 LinuxThreads that goes with it?</A></H4>
227 On <code>prep.ai.mit.edu</code> and its many, many mirrors around the world.
229 HREF="http://www.gnu.org/order/ftp.html">http://www.gnu.org/order/ftp.html</A>
230 for a list of mirrors.<P>
232 <H4><A NAME="C.5">C.5: Where can I find libc 5 and the version of
233 LinuxThreads that goes with it?</A></H4>
235 For libc 5, see <A HREF="ftp://sunsite.unc.edu/pub/Linux/devel/GCC/"><code>ftp://sunsite.unc.edu/pub/Linux/devel/GCC/</code></A>.<P>
237 For the libc 5 version of LinuxThreads, see
238 <A HREF="ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads/">ftp://ftp.inria.fr/INRIA/Projects/cristal/Xavier.Leroy/linuxthreads/</A>.<P>
240 <H4><A NAME="C.6">C.6: How can I recompile the glibc 2 version of the
241 LinuxThreads sources?</A></H4>
243 You must transfer the whole glibc sources, then drop the LinuxThreads
244 sources in the <code>linuxthreads/</code> subdirectory, then recompile
245 glibc as a whole. There are now too many inter-dependencies between
246 LinuxThreads and glibc 2 to allow separate re-compilation of LinuxThreads.
249 <H4><A NAME="C.7">C.7: What is the correspondence between LinuxThreads
250 version numbers, libc version numbers, and RedHat version
253 Here is a summary. (Information on Linux distributions other than
254 RedHat are welcome.)<P>
257 <TR><TD>LinuxThreads </TD> <TD>C library</TD> <TD>RedHat</TD></TR>
258 <TR><TD>0.7, 0.71 (for libc 5)</TD> <TD>libc 5.x</TD> <TD>RH 4.2</TD></TR>
259 <TR><TD>0.7, 0.71 (for glibc 2)</TD> <TD>glibc 2.0.x</TD> <TD>RH 5.x</TD></TR>
260 <TR><TD>0.8</TD> <TD>glibc 2.1.1</TD> <TD>RH 6.0</TD></TR>
261 <TR><TD>0.8</TD> <TD>glibc 2.1.2</TD> <TD>not yet released</TD></TR>
268 <H2><A NAME="D">D. Problems, weird behaviors, potential bugs</A></H2>
270 <H4><A NAME="D.1">D.1: When I compile LinuxThreads, I run into problems in
271 file <code>libc_r/dirent.c</code></A></H4>
275 libc_r/dirent.c:94: structure has no member named `dd_lock'
277 I haven't actually seen this problem, but several users reported it.
278 My understanding is that something is wrong in the include files of
279 your Linux installation (<code>/usr/include/*</code>). Make sure
280 you're using a supported version of the libc 5 library. (See question <A
281 HREF="#C.2">C.2</A>).<P>
283 <H4><A NAME="D.2">D.2: When I compile LinuxThreads, I run into problems with
284 <CODE>/usr/include/sched.h</CODE>: there are several occurrences of
285 <CODE>_p</CODE> that the C compiler does not understand</A></H4>
287 Yes, <CODE>/usr/include/sched.h</CODE> that comes with libc 5.3.12 is broken.
288 Replace it with the <code>sched.h</code> file contained in the
289 LinuxThreads distribution. But really you should not be using libc
290 5.3.12 with LinuxThreads! (See question <A HREF="#C.2">C.1</A>.)<P>
292 <H4><A NAME="D.3">D.3: My program does <CODE>fdopen()</CODE> on a file
293 descriptor opened on a pipe. When I link it with LinuxThreads,
294 <CODE>fdopen()</CODE> always returns NULL!</A></H4>
296 You're using one of the buggy versions of libc (5.3.12, 5.4.7., etc).
297 See question <A HREF="#C.1">C.1</A> above.<P>
299 <H4><A NAME="D.4">D.4: My program creates a lot of threads, and after
300 a while <CODE>pthread_create()</CODE> no longer returns!</A></H4>
302 This is known bug in the version of LinuxThreads that comes with glibc
303 2.1.1. An upgrade to 2.1.2 is recommended. <P>
305 <H4><A NAME="D.5">D.5: When I'm running a program that creates N
306 threads, <code>top</code> or <code>ps</code>
307 display N+2 processes that are running my program. What do all these
308 processes correspond to?</A></H4>
310 Due to the general "one process per thread" model, there's one process
311 for the initial thread and N processes for the threads it created
312 using <CODE>pthread_create</CODE>. That leaves one process
313 unaccounted for. That extra process corresponds to the "thread
314 manager" thread, a thread created internally by LinuxThreads to handle
315 thread creation and thread termination. This extra thread is asleep
318 <H4><A NAME="D.6">D.6: Scheduling seems to be very unfair when there
319 is strong contention on a mutex: instead of giving the mutex to each
320 thread in turn, it seems that it's almost always the same thread that
321 gets the mutex. Isn't this completely broken behavior?</A></H4>
323 That behavior has mostly disappeared in recent releases of
324 LinuxThreads (version 0.8 and up). It was fairly common in older
327 What happens in LinuxThreads 0.7 and before is the following: when a
328 thread unlocks a mutex, all other threads that were waiting on the
329 mutex are sent a signal which makes them runnable. However, the
330 kernel scheduler may or may not restart them immediately. If the
331 thread that unlocked the mutex tries to lock it again immediately
332 afterwards, it is likely that it will succeed, because the threads
333 haven't yet restarted. This results in an apparently very unfair
334 behavior, when the same thread repeatedly locks and unlocks the mutex,
335 while other threads can't lock the mutex.<P>
337 In LinuxThreads 0.8 and up, <code>pthread_unlock</code> restarts only
338 one waiting thread, and pre-assign the mutex to that thread. Hence,
339 if the thread that unlocked the mutex tries to lock it again
340 immediately, it will block until other waiting threads have had a
341 chance to lock and unlock the mutex. This results in much fairer
344 Notice however that even the old "unfair" behavior is perfectly
345 acceptable with respect to the POSIX standard: for the default
346 scheduling policy, POSIX makes no guarantees of fairness, such as "the
347 thread waiting for the mutex for the longest time always acquires it
348 first". Properly written multithreaded code avoids that kind of heavy
349 contention on mutexes, and does not run into fairness problems. If
350 you need scheduling guarantees, you should consider using the
351 real-time scheduling policies <code>SCHED_RR</code> and
352 <code>SCHED_FIFO</code>, which have precisely defined scheduling
355 <H4><A NAME="D.7">D.7: I have a simple test program with two threads
356 that do nothing but <CODE>printf()</CODE> in tight loops, and from the
357 printout it seems that only one thread is running, the other doesn't
358 print anything!</A></H4>
360 Again, this behavior is characteristic of old releases of LinuxThreads
361 (0.7 and before); more recent versions (0.8 and up) should not exhibit
364 The reason for this behavior is explained in
365 question <A HREF="#D.6">D.6</A> above: <CODE>printf()</CODE> performs
366 locking on <CODE>stdout</CODE>, and thus your two threads contend very
367 heavily for the mutex associated with <CODE>stdout</CODE>. But if you
368 do some real work between two calls to <CODE>printf()</CODE>, you'll
369 see that scheduling becomes much smoother.<P>
371 <H4><A NAME="D.8">D.8: I've looked at <code><pthread.h></code>
372 and there seems to be a gross error in the <code>pthread_cleanup_push</code>
373 macro: it opens a block with <code>{</code> but does not close it!
374 Surely you forgot a <code>}</code> at the end of the macro, right?
377 Nope. That's the way it should be. The closing brace is provided by
378 the <code>pthread_cleanup_pop</code> macro. The POSIX standard
379 requires <code>pthread_cleanup_push</code> and
380 <code>pthread_cleanup_pop</code> to be used in matching pairs, at the
381 same level of brace nesting. This allows
382 <code>pthread_cleanup_push</code> to open a block in order to
383 stack-allocate some data structure, and
384 <code>pthread_cleanup_pop</code> to close that block. It's ugly, but
385 it's the standard way of implementing cleanup handlers.<P>
387 <H4><A NAME="D.9">D.9: I tried to use real-time threads and my program
388 loops like crazy and freezes the whole machine!</A></H4>
390 Versions of LinuxThreads prior to 0.8 are susceptible to ``livelocks''
391 (one thread loops, consuming 100% of the CPU time) in conjunction with
392 real-time scheduling. Since real-time threads and processes have
393 higher priority than normal Linux processes, all other processes on
394 the machine, including the shell, the X server, etc, cannot run and
395 the machine appears frozen.<P>
397 The problem is fixed in LinuxThreads 0.8.<P>
399 <H4><A NAME="D.10">D.10: My application needs to create thousands of
400 threads, or maybe even more. Can I do this with
401 LinuxThreads?</A></H4>
403 No. You're going to run into several hard limits:
405 <LI>Each thread, from the kernel's standpoint, is one process. Stock
406 Linux kernels are limited to at most 512 processes for the super-user,
407 and half this number for regular users. This can be changed by
408 changing <code>NR_TASKS</code> in <code>include/linux/tasks.h</code>
409 and recompiling the kernel. On the x86 processors at least,
410 architectural constraints seem to limit <code>NR_TASKS</code> to 4090
412 <LI>LinuxThreads contains a table of all active threads. This table
413 has room for 1024 threads at most. To increase this limit, you must
414 change <code>PTHREAD_THREADS_MAX</code> in the LinuxThreads sources
416 <LI>By default, each thread reserves 2M of virtual memory space for
417 its stack. This space is just reserved; actual memory is allocated
418 for the stack on demand. But still, on a 32-bit processor, the total
419 virtual memory space available for the stacks is on the order of 1G,
420 meaning that more than 500 threads will have a hard time fitting in.
421 You can overcome this limitation by moving to a 64-bit platform, or by
422 allocating smaller stacks yourself using the <code>setstackaddr</code>
424 <LI>Finally, the Linux kernel contains many algorithms that run in
425 time proportional to the number of process table entries. Increasing
426 this number drastically will slow down the kernel operations
429 (Other POSIX threads libraries have similar limitations, by the way.)
430 For all those reasons, you'd better restructure your application so
431 that it doesn't need more than, say, 100 threads. For instance,
432 in the case of a multithreaded server, instead of creating a new
433 thread for each connection, maintain a fixed-size pool of worker
434 threads that pick incoming connection requests from a queue.<P>
439 <H2><A NAME="E">E. Missing functions, wrong types, etc</A></H2>
441 <H4><A NAME="E.1">E.1: Where is <CODE>pthread_yield()</CODE> ? How
442 comes LinuxThreads does not implement it?</A></H4>
444 Because it's not part of the (final) POSIX 1003.1c standard.
445 Several drafts of the standard contained <CODE>pthread_yield()</CODE>,
446 but then the POSIX guys discovered it was redundant with
447 <CODE>sched_yield()</CODE> and dropped it. So, just use
448 <CODE>sched_yield()</CODE> instead.
450 <H4><A NAME="E.2">E.2: I've found some type errors in
451 <code><pthread.h></code>.
452 For instance, the second argument to <CODE>pthread_create()</CODE>
453 should be a <CODE>pthread_attr_t</CODE>, not a
454 <CODE>pthread_attr_t *</CODE>. Also, didn't you forget to declare
455 <CODE>pthread_attr_default</CODE>?</A></H4>
457 No, I didn't. What you're describing is draft 4 of the POSIX
458 standard, which is used in OSF DCE threads. LinuxThreads conforms to the
459 final standard. Even though the functions have the same names as in
460 draft 4 and DCE, their calling conventions are slightly different. In
461 particular, attributes are passed by reference, not by value, and
462 default attributes are denoted by the NULL pointer. Since draft 4/DCE
463 will eventually disappear, you'd better port your program to use the
464 standard interface.<P>
466 <H4><A NAME="E.3">E.3: I'm porting an application from Solaris and I
467 have to rename all thread functions from <code>thr_blah</code> to
468 <CODE>pthread_blah</CODE>. This is very annoying. Why did you change
469 all the function names?</A></H4>
471 POSIX did it. The <code>thr_*</code> functions correspond to Solaris
472 threads, an older thread interface that you'll find only under
473 Solaris. The <CODE>pthread_*</CODE> functions correspond to POSIX
474 threads, an international standard available for many, many platforms.
475 Even Solaris 2.5 and later support the POSIX threads interface. So,
476 do yourself a favor and rewrite your code to use POSIX threads: this
477 way, it will run unchanged under Linux, Solaris, and quite a lot of
480 <H4><A NAME="E.4">E.4: How can I suspend and resume a thread from
481 another thread? Solaris has the <CODE>thr_suspend()</CODE> and
482 <CODE>thr_resume()</CODE> functions to do that; why don't you?</A></H4>
484 The POSIX standard provides <B>no</B> mechanism by which a thread A can
485 suspend the execution of another thread B, without cooperation from B.
486 The only way to implement a suspend/restart mechanism is to have B
487 check periodically some global variable for a suspend request
488 and then suspend itself on a condition variable, which another thread
489 can signal later to restart B.<P>
491 Notice that <CODE>thr_suspend()</CODE> is inherently dangerous and
492 prone to race conditions. For one thing, there is no control on where
493 the target thread stops: it can very well be stopped in the middle of
494 a critical section, while holding mutexes. Also, there is no
495 guarantee on when the target thread will actually stop. For these
496 reasons, you'd be much better off using mutexes and conditions
497 instead. The only situations that really require the ability to
498 suspend a thread are debuggers and some kind of garbage collectors.<P>
500 If you really must suspend a thread in LinuxThreads, you can send it a
501 <CODE>SIGSTOP</CODE> signal with <CODE>pthread_kill</CODE>. Send
502 <CODE>SIGCONT</CODE> for restarting it.
503 Beware, this is specific to LinuxThreads and entirely non-portable.
504 Indeed, a truly conforming POSIX threads implementation will stop all
505 threads when one thread receives the <CODE>SIGSTOP</CODE> signal!
506 One day, LinuxThreads will implement that behavior, and the
507 non-portable hack with <CODE>SIGSTOP</CODE> won't work anymore.<P>
509 <H4><A NAME="E.5">E.5: Does LinuxThreads implement
510 <CODE>pthread_attr_setstacksize()</CODE> and
511 <CODE>pthread_attr_setstackaddr()</CODE>?</A></H4>
513 These optional functions are provided in recent versions of
514 LinuxThreads (0.8 and up). Earlier releases did not provide these
515 optional components of the POSIX standard.<P>
517 Even if <CODE>pthread_attr_setstacksize()</CODE> and
518 <CODE>pthread_attr_setstackaddr()</CODE> are now provided, we still
519 recommend that you do not use them unless you really have strong
520 reasons for doing so. The default stack allocation strategy for
521 LinuxThreads is nearly optimal: stacks start small (4k) and
522 automatically grow on demand to a fairly large limit (2M).
523 Moreover, there is no portable way to estimate the stack requirements
524 of a thread, so setting the stack size yourself makes your program
525 less reliable and non-portable.<P>
527 <H4><A NAME="E.6">E.6: LinuxThreads does not support the
528 <CODE>PTHREAD_SCOPE_PROCESS</CODE> value of the "contentionscope"
529 attribute. Why? </A></H4>
531 With a "one-to-one" model, as in LinuxThreads (one kernel execution
532 context per thread), there is only one scheduler for all processes and
533 all threads on the system. So, there is no way to obtain the behavior of
534 <CODE>PTHREAD_SCOPE_PROCESS</CODE>.
536 <H4><A NAME="E.7">E.7: LinuxThreads does not implement process-shared
537 mutexes, conditions, and semaphores. Why?</A></H4>
539 This is another optional component of the POSIX standard. Portable
540 applications should test <CODE>_POSIX_THREAD_PROCESS_SHARED</CODE>
541 before using this facility.
543 The goal of this extension is to allow different processes (with
544 different address spaces) to synchronize through mutexes, conditions
545 or semaphores allocated in shared memory (either SVR4 shared memory
546 segments or <CODE>mmap()</CODE>ed files).
548 The reason why this does not work in LinuxThreads is that mutexes,
549 conditions, and semaphores are not self-contained: their waiting
550 queues contain pointers to linked lists of thread descriptors, and
551 these pointers are meaningful only in one address space.
553 Matt Messier and I spent a significant amount of time trying to design a
554 suitable mechanism for sharing waiting queues between processes. We
555 came up with several solutions that combined two of the following
556 three desirable features, but none that combines all three:
558 <LI>allow sharing between processes having different UIDs
559 <LI>supports cancellation
560 <LI>supports <CODE>pthread_cond_timedwait</CODE>
562 We concluded that kernel support is required to share mutexes,
563 conditions and semaphores between processes. That's one place where
564 Linus Torvalds's intuition that "all we need in the kernel is
565 <CODE>clone()</CODE>" fails.
567 Until suitable kernel support is available, you'd better use
568 traditional interprocess communications to synchronize different
569 processes: System V semaphores and message queues, or pipes, or sockets.
575 <H2><A NAME="F">F. C++ issues</A></H2>
577 <H4><A NAME="F.1">F.1: Are there C++ wrappers for LinuxThreads?</A></H4>
579 Douglas Schmidt's ACE library contains, among a lot of other
580 things, C++ wrappers for LinuxThreads and quite a number of other
581 thread libraries. Check out
582 <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">http://www.cs.wustl.edu/~schmidt/ACE.html</A><P>
584 <H4><A NAME="F.2">F.2: I'm trying to use LinuxThreads from a C++
585 program, and the compiler complains about the third argument to
586 <CODE>pthread_create()</CODE> !</A></H4>
588 You're probably trying to pass a class member function or some
589 other C++ thing as third argument to <CODE>pthread_create()</CODE>.
590 Recall that <CODE>pthread_create()</CODE> is a C function, and it must
591 be passed a C function as third argument.<P>
593 <H4><A NAME="F.3">F.3: I'm trying to use LinuxThreads in conjunction
594 with libg++, and I'm having all sorts of trouble.</A></H4>
596 >From what I understand, thread support in libg++ is completely broken,
597 especially with respect to locking of iostreams. H.J.Lu wrote:
599 If you want to use thread, I can only suggest egcs and glibc. You
601 <A HREF="http://www.cygnus.com/egcs">http://www.cygnus.com/egcs</A>.
602 egcs has libsdtc++, which is MT safe under glibc 2. If you really
603 want to use the libg++, I have a libg++ add-on for egcs.
608 <H2><A NAME="G">G. Debugging LinuxThreads programs</A></H2>
610 <H4><A NAME="G.1">G.1: Can I debug LinuxThreads program using gdb?</A></H4>
612 Yes, but not with the stock gdb 4.17. You need a specially patched
613 version of gdb 4.17 developed by Eric Paire and colleages at The Open
614 Group, Grenoble. The patches against gdb 4.17 are available at
615 <A HREF="http://www.gr.opengroup.org/java/jdk/linux/debug.htm"><code>http://www.gr.opengroup.org/java/jdk/linux/debug.htm</code></A>.
616 Precompiled binaries of the patched gdb are available in RedHat's RPM
618 HREF="http://odin.appliedtheory.com/"><code>http://odin.appliedtheory.com/</code></A>.<P>
620 Some Linux distributions provide an already-patched version of gdb;
621 others don't. For instance, the gdb in RedHat 5.2 is thread-aware,
622 but apparently not the one in RedHat 6.0. Just ask (politely) the
623 makers of your Linux distributions to please make sure that they apply
624 the correct patches to gdb.<P>
626 <H4><A NAME="G.2">G.2: Does it work with post-mortem debugging?</A></H4>
628 Not very well. Generally, the core file does not correspond to the
629 thread that crashed. The reason is that the kernel will not dump core
630 for a process that shares its memory with other processes, such as the
631 other threads of your program. So, the thread that crashes silently
632 disappears without generating a core file. Then, all other threads of
633 your program die on the same signal that killed the crashing thread.
634 (This is required behavior according to the POSIX standard.) The last
635 one that dies is no longer sharing its memory with anyone else, so the
636 kernel generates a core file for that thread. Unfortunately, that's
637 not the thread you are interested in.
639 <H4><A NAME="G.3">G.3: Any other ways to debug multithreaded programs, then?</A></H4>
641 Assertions and <CODE>printf()</CODE> are your best friends. Try to debug
642 sequential parts in a single-threaded program first. Then, put
643 <CODE>printf()</CODE> statements all over the place to get execution traces.
644 Also, check invariants often with the <CODE>assert()</CODE> macro. In truth,
645 there is no other effective way (save for a full formal proof of your
646 program) to track down concurrency bugs. Debuggers are not really
647 effective for subtle concurrency problems, because they disrupt
648 program execution too much.<P>
653 <H2><A NAME="H">H. Compiling multithreaded code; errno madness</A></H2>
655 <H4><A NAME="H.1">H.1: You say all multithreaded code must be compiled
656 with <CODE>_REENTRANT</CODE> defined. What difference does it make?</A></H4>
658 It affects include files in three ways:
660 <LI> The include files define prototypes for the reentrant variants of
661 some of the standard library functions,
662 e.g. <CODE>gethostbyname_r()</CODE> as a reentrant equivalent to
663 <CODE>gethostbyname()</CODE>.<P>
665 <LI> If <CODE>_REENTRANT</CODE> is defined, some
666 <code><stdio.h></code> functions are no longer defined as macros,
667 e.g. <CODE>getc()</CODE> and <CODE>putc()</CODE>. In a multithreaded
668 program, stdio functions require additional locking, which the macros
669 don't perform, so we must call functions instead.<P>
671 <LI> More importantly, <code><errno.h></code> redefines errno when
672 <CODE>_REENTRANT</CODE> is
673 defined, so that errno refers to the thread-specific errno location
674 rather than the global errno variable. This is achieved by the
675 following <code>#define</code> in <code><errno.h></code>:
677 #define errno (*(__errno_location()))
679 which causes each reference to errno to call the
680 <CODE>__errno_location()</CODE> function for obtaining the location
681 where error codes are stored. libc provides a default definition of
682 <CODE>__errno_location()</CODE> that always returns
683 <code>&errno</code> (the address of the global errno variable). Thus,
684 for programs not linked with LinuxThreads, defining
685 <CODE>_REENTRANT</CODE> makes no difference w.r.t. errno processing.
686 But LinuxThreads redefines <CODE>__errno_location()</CODE> to return a
687 location in the thread descriptor reserved for holding the current
688 value of errno for the calling thread. Thus, each thread operates on
689 a different errno location.
693 <H4><A NAME="H.2">H.2: Why is it so important that each thread has its
694 own errno variable? </A></H4>
696 If all threads were to store error codes in the same, global errno
697 variable, then the value of errno after a system call or library
698 function returns would be unpredictable: between the time a system
699 call stores its error code in the global errno and your code inspects
700 errno to see which error occurred, another thread might have stored
701 another error code in the same errno location. <P>
703 <H4><A NAME="H.3">H.3: What happens if I link LinuxThreads with code
704 not compiled with <CODE>-D_REENTRANT</CODE>?</A></H4>
706 Lots of trouble. If the code uses <CODE>getc()</CODE> or
707 <CODE>putc()</CODE>, it will perform I/O without proper interlocking
708 of the stdio buffers; this can cause lost output, duplicate output, or
709 just crash other stdio functions. If the code consults errno, it will
710 get back the wrong error code. The following code fragment is a
714 r = read(fd, buf, n);
716 if (errno == EINTR) /* an error we can handle */
718 else { /* other errors are fatal */
719 perror("read failed");
725 Assume this code is not compiled with <CODE>-D_REENTRANT</CODE>, and
726 linked with LinuxThreads. At run-time, <CODE>read()</CODE> is
727 interrupted. Since the C library was compiled with
728 <CODE>-D_REENTRANT</CODE>, <CODE>read()</CODE> stores its error code
729 in the location pointed to by <CODE>__errno_location()</CODE>, which
730 is the thread-local errno variable. Then, the code above sees that
731 <CODE>read()</CODE> returns -1 and looks up errno. Since
732 <CODE>_REENTRANT</CODE> is not defined, the reference to errno
733 accesses the global errno variable, which is most likely 0. Hence the
734 code concludes that it cannot handle the error and stops.<P>
736 <H4><A NAME="H.4">H.4: With LinuxThreads, I can no longer use the signals
737 <code>SIGUSR1</code> and <code>SIGUSR2</code> in my programs! Why? </A></H4>
739 The short answer is: because the Linux kernel you're using does not
740 support realtime signals. <P>
742 LinuxThreads needs two signals for its internal operation.
743 One is used to suspend and restart threads blocked on mutex, condition
744 or semaphore operations. The other is used for thread
747 On ``old'' kernels (2.0 and early 2.1 kernels), there are only 32
748 signals available and the kernel reserves all of them but two:
749 <code>SIGUSR1</code> and <code>SIGUSR2</code>. So, LinuxThreads has
750 no choice but use those two signals.<P>
752 On recent kernels (2.2 and up), more than 32 signals are provided in
753 the form of realtime signals. When run on one of those kernels,
754 LinuxThreads uses two reserved realtime signals for its internal
755 operation, thus leaving <code>SIGUSR1</code> and <code>SIGUSR2</code>
756 free for user code. (This works only with glibc, not with libc 5.) <P>
758 <H4><A NAME="H.5">H.5: Is the stack of one thread visible from the
759 other threads? Can I pass a pointer into my stack to other threads?
762 Yes, you can -- if you're very careful. The stacks are indeed visible
763 from all threads in the system. Some non-POSIX thread libraries seem
764 to map the stacks for all threads at the same virtual addresses and
765 change the memory mapping when they switch from one thread to
766 another. But this is not the case for LinuxThreads, as it would make
767 context switching between threads more expensive, and at any rate
768 might not conform to the POSIX standard.<P>
770 So, you can take the address of an "auto" variable and pass it to
771 other threads via shared data structures. However, you need to make
772 absolutely sure that the function doing this will not return as long
773 as other threads need to access this address. It's the usual mistake
774 of returning the address of an "auto" variable, only made much worse
775 because of concurrency. It's much, much safer to systematically
776 heap-allocate all shared data structures. <P>
781 <H2><A NAME="I">I. X-Windows and other libraries</A></H2>
783 <H4><A NAME="I.1">I.1: My program uses both Xlib and LinuxThreads.
784 It stops very early with an "Xlib: unknown 0 error" message. What
785 does this mean? </A></H4>
787 That's a prime example of the errno problem described in question <A
788 HREF="#H.2">H.2</A>. The binaries for Xlib you're using have not been
789 compiled with <CODE>-D_REENTRANT</CODE>. It happens Xlib contains a
790 piece of code very much like the one in question <A
791 HREF="#H.2">H.2</A>. So, your Xlib fetches the error code from the
792 wrong errno location and concludes that an error it cannot handle
795 <H4><A NAME="I.2">I.2: So, what can I do to build a multithreaded X
796 Windows client? </A></H4>
798 The best solution is to use X libraries that have been compiled with
799 multithreading options set. Linux distributions that come with glibc
800 2 as the main C library generally provide thread-safe X libraries.
801 At least, that seems to be the case for RedHat 5 and later.<P>
803 You can try to recompile yourself the X libraries with multithreading
804 options set. They contain optional support for multithreading; it's
805 just that the binaries provided by your Linux distribution were built
806 without this support. See the file <code>README.Xfree3.3</code> in
807 the LinuxThreads distribution for patches and info on how to compile
808 thread-safe X libraries from the Xfree3.3 distribution. The Xfree3.3
809 sources are readily available in most Linux distributions, e.g. as a
810 source RPM for RedHat. Be warned, however, that X Windows is a huge
811 system, and recompiling even just the libraries takes a lot of time
814 Another, less involving solution is to call X functions only from the
815 main thread of your program. Even if all threads have their own errno
816 location, the main thread uses the global errno variable for its errno
817 location. Thus, code not compiled with <code>-D_REENTRANT</code>
818 still "sees" the right error values if it executes in the main thread
821 <H4><A NAME="I.2">This is a lot of work. Don't you have precompiled
822 thread-safe X libraries that you could distribute?</A></H4>
824 No, I don't. Sorry. But consider installing a Linux distribution
825 that comes with thread-safe X libraries, such as RedHat 6.<P>
827 <H4><A NAME="I.3">I.3: Can I use library FOO in a multithreaded
830 Most libraries cannot be used "as is" in a multithreaded program.
831 For one thing, they are not necessarily thread-safe: calling
832 simultaneously two functions of the library from two threads might not
833 work, due to internal use of global variables and the like. Second,
834 the libraries must have been compiled with <CODE>-D_REENTRANT</CODE> to avoid
835 the errno problems explained in question <A HREF="#H.2">H.2</A>.
838 <H4><A NAME="I.4">I.4: What if I make sure that only one thread calls
839 functions in these libraries?</A></H4>
841 This avoids problems with the library not being thread-safe. But
842 you're still vulnerable to errno problems. At the very least, a
843 recompile of the library with <CODE>-D_REENTRANT</CODE> is needed.
846 <H4><A NAME="I.5">I.5: What if I make sure that only the main thread
847 calls functions in these libraries?</A></H4>
849 That might actually work. As explained in question <A HREF="#I.1">I.1</A>,
850 the main thread uses the global errno variable, and can therefore
851 execute code not compiled with <CODE>-D_REENTRANT</CODE>.<P>
853 <H4><A NAME="I.6">I.6: SVGAlib doesn't work with LinuxThreads. Why?
856 Because both LinuxThreads and SVGAlib use the signals
857 <code>SIGUSR1</code> and <code>SIGUSR2</code>. See question <A
865 <H2><A NAME="J">J. Signals and threads</A></H2>
867 <H4><A NAME="J.1">J.1: When it comes to signals, what is shared
868 between threads and what isn't?</A></H4>
870 Signal handlers are shared between all threads: when a thread calls
871 <CODE>sigaction()</CODE>, it sets how the signal is handled not only
872 for itself, but for all other threads in the program as well.<P>
874 On the other hand, signal masks are per-thread: each thread chooses
875 which signals it blocks independently of others. At thread creation
876 time, the newly created thread inherits the signal mask of the thread
877 calling <CODE>pthread_create()</CODE>. But afterwards, the new thread
878 can modify its signal mask independently of its creator thread.<P>
880 <H4><A NAME="J.2">J.2: When I send a <CODE>SIGKILL</CODE> to a
881 particular thread using <CODE>pthread_kill</CODE>, all my threads are
884 That's how it should be. The POSIX standard mandates that all threads
885 should terminate when the process (i.e. the collection of all threads
886 running the program) receives a signal whose effect is to
887 terminate the process (such as <CODE>SIGKILL</CODE> or <CODE>SIGINT</CODE>
888 when no handler is installed on that signal). This behavior makes a
889 lot of sense: when you type "ctrl-C" at the keyboard, or when a thread
890 crashes on a division by zero or a segmentation fault, you really want
891 all threads to stop immediately, not just the one that caused the
892 segmentation violation or that got the <CODE>SIGINT</CODE> signal.
893 (This assumes default behavior for those signals; see question
894 <A HREF="#J.3">J.3</A> if you install handlers for those signals.)<P>
896 If you're trying to terminate a thread without bringing the whole
897 process down, use <code>pthread_cancel()</code>.<P>
899 <H4><A NAME="J.3">J.3: I've installed a handler on a signal. Which
900 thread executes the handler when the signal is received?</A></H4>
902 If the signal is generated by a thread during its execution (e.g. a
903 thread executes a division by zero and thus generates a
904 <CODE>SIGFPE</CODE> signal), then the handler is executed by that
905 thread. This also applies to signals generated by
906 <CODE>raise()</CODE>.<P>
908 If the signal is sent to a particular thread using
909 <CODE>pthread_kill()</CODE>, then that thread executes the handler.<P>
911 If the signal is sent via <CODE>kill()</CODE> or the tty interface
912 (e.g. by pressing ctrl-C), then the POSIX specs say that the handler
913 is executed by any thread in the process that does not currently block
914 the signal. In other terms, POSIX considers that the signal is sent
915 to the process (the collection of all threads) as a whole, and any
916 thread that is not blocking this signal can then handle it.<P>
918 The latter case is where LinuxThreads departs from the POSIX specs.
919 In LinuxThreads, there is no real notion of ``the process as a whole'':
920 in the kernel, each thread is really a distinct process with a
921 distinct PID, and signals sent to the PID of a thread can only be
922 handled by that thread. As long as no thread is blocking the signal,
923 the behavior conforms to the standard: one (unspecified) thread of the
924 program handles the signal. But if the thread to which PID the signal
925 is sent blocks the signal, and some other thread does not block the
926 signal, then LinuxThreads will simply queue in
927 that thread and execute the handler only when that thread unblocks
928 the signal, instead of executing the handler immediately in the other
929 thread that does not block the signal.<P>
931 This is to be viewed as a LinuxThreads bug, but I currently don't see
932 any way to implement the POSIX behavior without kernel support.<P>
934 <H4><A NAME="J.3">J.3: How shall I go about mixing signals and threads
935 in my program? </A></H4>
937 The less you mix them, the better. Notice that all
938 <CODE>pthread_*</CODE> functions are not async-signal safe, meaning
939 that you should not call them from signal handlers. This
940 recommendation is not to be taken lightly: your program can deadlock
941 if you call a <CODE>pthread_*</CODE> function from a signal handler!
944 The only sensible things you can do from a signal handler is set a
945 global flag, or call <CODE>sem_post</CODE> on a semaphore, to record
946 the delivery of the signal. The remainder of the program can then
947 either poll the global flag, or use <CODE>sem_wait()</CODE> and
948 <CODE>sem_trywait()</CODE> on the semaphore.<P>
950 Another option is to do nothing in the signal handler, and dedicate
951 one thread (preferably the initial thread) to wait synchronously for
952 signals, using <CODE>sigwait()</CODE>, and send messages to the other
955 <H4><A NAME="J.4">J.4: When one thread is blocked in
956 <CODE>sigwait()</CODE>, other threads no longer receive the signals
957 <CODE>sigwait()</CODE> is waiting for! What happens? </A></H4>
959 It's an unfortunate consequence of how LinuxThreads implements
960 <CODE>sigwait()</CODE>. Basically, it installs signal handlers on all
961 signals waited for, in order to record which signal was received.
962 Since signal handlers are shared with the other threads, this
963 temporarily deactivates any signal handlers you might have previously
964 installed on these signals.<P>
966 Though surprising, this behavior actually seems to conform to the
967 POSIX standard. According to POSIX, <CODE>sigwait()</CODE> is
968 guaranteed to work as expected only if all other threads in the
969 program block the signals waited for (otherwise, the signals could be
970 delivered to other threads than the one doing <CODE>sigwait()</CODE>,
971 which would make <CODE>sigwait()</CODE> useless). In this particular
972 case, the problem described in this question does not appear.<P>
974 One day, <CODE>sigwait()</CODE> will be implemented in the kernel,
975 along with others POSIX 1003.1b extensions, and <CODE>sigwait()</CODE>
976 will have a more natural behavior (as well as better performances).<P>
981 <H2><A NAME="K">K. Internals of LinuxThreads</A></H2>
983 <H4><A NAME="K.1">K.1: What is the implementation model for
984 LinuxThreads?</A></H4>
986 LinuxThreads follows the so-called "one-to-one" model: each thread is
987 actually a separate process in the kernel. The kernel scheduler takes
988 care of scheduling the threads, just like it schedules regular
989 processes. The threads are created with the Linux
990 <code>clone()</code> system call, which is a generalization of
991 <code>fork()</code> allowing the new process to share the memory
992 space, file descriptors, and signal handlers of the parent.<P>
994 Advantages of the "one-to-one" model include:
996 <LI> minimal overhead on CPU-intensive multiprocessing (with
997 about one thread per processor);
998 <LI> minimal overhead on I/O operations;
999 <LI> a simple and robust implementation (the kernel scheduler does
1000 most of the hard work for us).
1002 The main disadvantage is more expensive context switches on mutex and
1003 condition operations, which must go through the kernel. This is
1004 mitigated by the fact that context switches in the Linux kernel are
1005 pretty efficient.<P>
1007 <H4><A NAME="K.2">K.2: Have you considered other implementation
1010 There are basically two other models. The "many-to-one" model
1011 relies on a user-level scheduler that context-switches between the
1012 threads entirely in user code; viewed from the kernel, there is only
1013 one process running. This model is completely out of the question for
1014 me, since it does not take advantage of multiprocessors, and require
1015 unholy magic to handle blocking I/O operations properly. There are
1016 several user-level thread libraries available for Linux, but I found
1017 all of them deficient in functionality, performance, and/or robustness.
1020 The "many-to-many" model combines both kernel-level and user-level
1021 scheduling: several kernel-level threads run concurrently, each
1022 executing a user-level scheduler that selects between user threads.
1023 Most commercial Unix systems (Solaris, Digital Unix, IRIX) implement
1024 POSIX threads this way. This model combines the advantages of both
1025 the "many-to-one" and the "one-to-one" model, and is attractive
1026 because it avoids the worst-case behaviors of both models --
1027 especially on kernels where context switches are expensive, such as
1028 Digital Unix. Unfortunately, it is pretty complex to implement, and
1029 requires kernel support which Linux does not provide. Linus Torvalds
1030 and other Linux kernel developers have always been pushing the
1031 "one-to-one" model in the name of overall simplicity, and are doing a
1032 pretty good job of making kernel-level context switches between
1033 threads efficient. LinuxThreads is just following the general
1034 direction they set.<P>
1037 <ADDRESS>Xavier.Leroy@inria.fr</ADDRESS>
OSDN Git Service
