>Apologies to anyone who doesn't think this belongs in an advocacy
>I am after some information on programming with threads, for Linux.
>Actually, I'm quite interested in the implementation of threads for the
>Unices in general, since it seems that the relatively recent adoption of
>this multitasking model is one of the few technical areas where Unix
>falls behind the likes of NT.
This is sheer nonsense perpetrated by microserfs. UNIX has been a prominent
research platform in the move to threads. If I recall, the comp.threads FAQ
mentions only UNIX in the question about the history of threads.
Microsoft threading is just a non-standard variant derived from OS/2 threads.
It doesn't conform to any standard API such as POSIX, and provides
synchronization primitives that are exceedingly clumsy and ill-conceived,
and require the use of handles.
Quote:>What is the difference between the so called 'PosixThreads' and
>'LinuxThreads', 'SolarisThreads', and whatever other permutations exist?
They are all very similar. LinuxThreads strives for POSIX 1003.1c compliance.
It meets the standard in all but a few ways; one of the requirements that
cannot be met easily is the requirement that the threads share the same
process ID---in Linux, each thread has its own PID.
I can't imagine a useful program which would depend on this behavior.
People doing threaded programming in the UNIX world most likely cannot
afford to not be aware of this incompatibility. :)
Solaris threads are not POSIX, but they are quite similar. It's not difficult
to develop sofware that can use either; for example, the thread-safe
exception handling code in recent EGCS snapshots will readily use DCE,
Solaris or POSIX threads.
I believe, though I could be wrong, that Solaris threads are based on a
somewhat earlier draft of the POSIX threads standard.
Quote:>I'm running Linux, kernel 2.0.29. I'm not even entirely sure whether
>this particular build actually supports threads at all (do please
Yes, that kernel definitely supports threads. Kernel threads were known to
work in the 1.3 series kernels already. What's more, the threading does
support SMP; threads can be independently scheduled on multiple processors.
I'm developing with threads on a SMP Linux system with two processors.
Quote:>Assuming it does, where can I get hold of information
>about such programming? I'm not really keen on buying a book on it, I'd
>rather download some roughly put together text file and/or a working
>example or two; that'd be plenty sufficient.
That is the home page of the author of LinuxThreads, the API library
provides POSIX threads over top of the Linux clone() system call and other
facilities. You can download the package by following links on that page.
Read the FAQ's and observe the shared library requirements. There are also
links to programming examples, tutorials and the like.
You _can_ use LinuxThreads with libc5, and a specially adapted version of
LinuxThreads appears in glibc2, so if you have that, you don't have to install
LinuxThreads separately. The stand-alone LinuxThreads, when linked in,
overrides some of your existing library functions (such as malloc, etc) to
make them thread safe. Moreover, it supplies reentrant versions of some
functions, such as gethostbyname_r, which you should use instead of
If you plan to be doing multi-threaded C++ development, and want to use
exception handling in more than one thread, you have to get the EGCS
distribution of GCC, a snapshot no earlier than 980308. Before installing
it, edit the file gcc/gthr.h, and add #define __GTHREADS 1 and
#define _PTHREADS 1 at the top. This will ensure that a libgcc.a with
the thread-safe exception handling stuff gets built. You have to have
LinuxThreads installed first, since the <pthread.h> header file is
The comp.threads FAQ says that LinuxThreads is beta, but allegedly very
stable. My personal observations support this.