| blob | 21be33ec4c61d346c6825b641ac1aafae1742bf2 |
1 <HTML>
2 <HEAD>
4 </HEAD>
5 <BODY>
7 (with answers)</H1>
10 <HR><P>
24 <HR>
25 <P>
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
35 <P>
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>
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
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
72 platforms.<P>
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
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
85 completed.<P>
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
94 fixes all of those problems and is now the standard C library on major
97 <HR>
98 <P>
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>
113 LinuxThreads. Is there a mailing list for this purpose?</A></H4>
115 I post LinuxThreads-related announcements on the newsgroup
117 and also on the mailing list
119 You can subscribe to the latter by writing
123 LinuxThreads?</A></H4>
125 For questions about programming with POSIX threads in general, use
126 the newsgroup
128 Be sure you read the
130 for this group before you post.<P>
132 For Linux-specific questions, use
133 <A
135 and <A
137 The latter is especially appropriate for questions relative to the
138 interface between the kernel and LinuxThreads.<P>
141 LinuxThreads?</A></H4>
143 If you're using glibc 2, the best way by far is to use the
145 maintainers. <P>
148 script on your machine, then e-mail me directly
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>
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
175 and as a
177 That specification includes pretty much all the POSIX standards,
180 <HR>
181 <P>
186 with LinuxThreads?</A></H4>
189 support for multi-threading, and LinuxThreads has been closely
191 sources of a specially adapted version of LinuxThreads.<P>
193 glibc 2 comes preinstalled as the default C library on several Linux
195 Those distributions include the version of LinuxThreads matching
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
208 variable. <P>
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
216 multi-threaded programming.<P>
218 Switching an already installed
221 HOWTO</A> for more information. Much easier is (re-)installing a
225 LinuxThreads that goes with it?</A></H4>
228 See <A
230 for a list of mirrors.<P>
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>
241 LinuxThreads sources?</A></H4>
243 You must transfer the whole glibc sources, then drop the LinuxThreads
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.
247 <P>
250 version numbers, libc version numbers, and RedHat version
251 numbers?</A></H4>
253 Here is a summary. (Information on Linux distributions other than
254 RedHat are welcome.)<P>
256 <TABLE>
262 </TABLE>
263 <P>
265 <HR>
266 <P>
273 You probably mean:
274 <PRE>
275 libc_r/dirent.c:94: structure has no member named `dd_lock'
276 </PRE>
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
289 LinuxThreads distribution. But really you should not be using libc
293 descriptor opened on a pipe. When I link it with LinuxThreads,
302 This is known bug in the version of LinuxThreads that comes with glibc
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
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
316 most of the time.
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
325 releases, though.
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>
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
342 scheduling.<P>
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
353 behaviors. <P>
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
362 this behavior.<P>
364 The reason for this behavior is explained in
369 see that scheduling becomes much smoother.<P>
375 </A></H4>
377 Nope. That's the way it should be. The closing brace is provided by
381 same level of brace nesting. This allows
383 stack-allocate some data structure, and
385 it's the standard way of implementing cleanup handlers.<P>
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>
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:
404 <UL>
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
409 and recompiling the kernel. On the x86 processors at least,
411 at most.
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
415 and recompile.
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
423 attribute.
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
427 noticeably.
428 </UL>
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>
436 <HR>
437 <P>
442 comes LinuxThreads does not implement it?</A></H4>
444 Because it's not part of the (final) POSIX 1003.1c standard.
446 but then the POSIX guys discovered it was redundant with
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>
469 all the function names?</A></H4>
472 threads, an older thread interface that you'll find only under
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
478 other platforms.<P>
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>
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
503 Beware, this is specific to LinuxThreads and entirely non-portable.
504 Indeed, a truly conforming POSIX threads implementation will stop all
506 One day, LinuxThreads will implement that behavior, and the
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>
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>
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
537 mutexes, conditions, and semaphores. Why?</A></H4>
539 This is another optional component of the POSIX standard. Portable
541 before using this facility.
542 <P>
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
547 <P>
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.
552 <P>
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:
557 <UL>
558 <LI>allow sharing between processes having different UIDs
559 <LI>supports cancellation
561 </UL>
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.
566 <P>
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.
570 <P>
572 <HR>
573 <P>
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>
585 program, and the compiler complains about the third argument to
588 You're probably trying to pass a class member function or some
591 be passed a C function as third argument.<P>
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:
598 <BLOCKQUOTE>
599 If you want to use thread, I can only suggest egcs and glibc. You
600 can find egcs at
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.
604 </BLOCKQUOTE>
605 <HR>
606 <P>
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
617 format at <A
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>
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.
642 sequential parts in a single-threaded program first. Then, put
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>
650 <HR>
651 <P>
658 It affects include files in three ways:
659 <UL>
660 <LI> The include files define prototypes for the reentrant variants of
661 some of the standard library functions,
668 program, stdio functions require additional locking, which the macros
669 don't perform, so we must call functions instead.<P>
673 defined, so that errno refers to the thread-specific errno location
674 rather than the global errno variable. This is achieved by the
676 <PRE>
677 #define errno (*(__errno_location()))
678 </PRE>
679 which causes each reference to errno to call the
681 where error codes are stored. libc provides a default definition of
684 for programs not linked with LinuxThreads, defining
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.
690 </UL>
691 <P>
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>
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
711 typical example:
712 <PRE>
713 do {
714 r = read(fd, buf, n);
715 if (r == -1) {
716 if (errno == EINTR) /* an error we can handle */
717 continue;
718 else { /* other errors are fatal */
719 perror("read failed");
720 exit(100);
721 }
722 }
723 } while (...);
724 </PRE>
727 interrupted. Since the C library was compiled with
730 is the thread-local errno variable. Then, the code above sees that
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>
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
745 cancellation.<P>
748 signals available and the kernel reserves all of them but two:
750 no choice but use those two signals.<P>
753 the form of realtime signals. When run on one of those kernels,
754 LinuxThreads uses two reserved realtime signals for its internal
759 other threads? Can I pass a pointer into my stack to other threads?
760 </A></H4>
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>
778 <HR>
779 <P>
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
790 piece of code very much like the one in question <A
792 wrong errno location and concludes that an error it cannot handle
793 occurred.<P>
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.
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
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
812 and disk space.<P>
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
818 still "sees" the right error values if it executes in the main thread
819 only. <P>
822 thread-safe X libraries that you could distribute?</A></H4>
824 No, I don't. Sorry. But consider installing a Linux distribution
828 program?</A></H4>
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,
836 <P>
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
844 <P>
847 calls functions in these libraries?</A></H4>
850 the main thread uses the global errno variable, and can therefore
854 </A></H4>
856 Because both LinuxThreads and SVGAlib use the signals
859 <P>
862 <HR>
863 <P>
868 between threads and what isn't?</A></H4>
870 Signal handlers are shared between all threads: when a thread calls
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
878 can modify its signal mask independently of its creator thread.<P>
882 killed!</A></H4>
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
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
893 (This assumes default behavior for those signals; see question
896 If you're trying to terminate a thread without bringing the whole
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
905 thread. This also applies to signals generated by
908 If the signal is sent to a particular thread using
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>
935 in my program? </A></H4>
937 The less you mix them, the better. Notice that all
939 that you should not call them from signal handlers. This
940 recommendation is not to be taken lightly: your program can deadlock
942 <P>
944 The only sensible things you can do from a signal handler is set a
946 the delivery of the signal. The remainder of the program can then
950 Another option is to do nothing in the signal handler, and dedicate
951 one thread (preferably the initial thread) to wait synchronously for
953 threads accordingly.
959 It's an unfortunate consequence of how LinuxThreads implements
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
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
972 case, the problem described in this question does not appear.<P>
976 will have a more natural behavior (as well as better performances).<P>
978 <HR>
979 <P>
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
992 space, file descriptors, and signal handlers of the parent.<P>
994 Advantages of the "one-to-one" model include:
995 <UL>
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).
1001 </UL>
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>
1008 models?</A></H4>
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.
1018 <P>
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
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>
1036 <HR>
1038 </BODY>
1039 </HTML>