Comparison of thread implementations

Vendor	Release	PCS	SCS	SUSv2	1003.1c	DCE	Notes
Sun	Solaris 1 (SunOS 4.x)	User	No	No	No	No	liblwp
	Solaris 2.0	Yes	Yes	No	No	No	UI threads
	Solaris 2.5	Yes	Yes	No	Yes	No	UI threads
	Solaris 7	Yes	Yes	Yes	Yes	No	UI threads
Compaq	DEC OSF/1 (to 3.2G)	No	Yes	No	No	Yes	CMA
	OpenVMS 5.5-2	User	No	No	No	Yes	CMA
	Digital UNIX 4.0	Yes	No	No	Yes	Yes	CMA
	Digital UNIX 4.0D	Yes	Yes	No	Yes	Yes	CMA
	Tru64 UNIX 5.0	Yes	Yes	(almost)	Yes	Yes	CMA
	OpenVMS 7.0	Yes	No	No	(almost)	Yes	CMA
SGI	IRIX 6.0	No	Yes	No	No	No	sproc
	IRIX 6.2 (with patches)	Yes	No	No	Yes	No
	IRIX 6.5	Yes	Yes	No	Yes	No
IBM	AIX (to 4.0)	User	No	No	No	Yes
	AIX 4.1	No	Yes	No	No	No	"Draft 7"
	AIX 4.3	No	Yes	(almost)	Yes	No
	AIX 4.3.1	Yes	Yes	Yes	Yes	No
	OS/400 v4r2	??	??	No	(almost)	No
	OS/2	No	Yes	No	No	No	OS/2
HP	HP-UX (to 10.20)	User	No	No	No	Yes
	HP-UX 10.30 (limited support)	No	Yes	No	Yes	No
	HP-UX 11.0	No	Yes	Yes	Yes	No
SCO	UnixWare 2	Yes	Yes	No	No	No	UI threads
	UnixWare 7	Yes	Yes	No	Yes	No	UI threads
Linux	Linux 2.2 with LinuxThreads	No	Yes	No	(almost)	No
Apple	Mac OS X server	No	Yes	No	No	No	cthreads
	Mac OS X client	??	Yes	No	Yes	No	cthreads
Microsoft	Windows 95/98, NT	No	Yes	No	No	No	Win32

Notes

• "PCS" means "Process Contention Scope", the ability to schedule threads with (in theory) less overhead within the process. "Yes" refers to 2-level scheduling, of some variety, where user threads are scheduled on multiple "kernel execution entities". "User" refers to a library that emulates true threads on top of a single process. On all PCS implementations of which I'm aware that also support SCS, PCS is the default. Under POSIX or SUSv2, you can create a thread under SCS using the pthread_attr_setscope() function.
• "SCS" means "System Contention Scope", where the kernel schedules all threads along with processes.
• "SUSv2" refers to the Single UNIX Specification, Version 2 (aka UNIX98), which extends the POSIX 1003.1c both by adding new interfaces and by solidifying some subtle but important semantics of the POSIX standard. SUSv2 also provides impartial validation for conformance via the UNIX98 brand, whereas POSIX provides no methodology or mechanism for conformance testing. (Therefore, even aside from the extra features, there is more value in SUSv2 than in POSIX.) The notation "(almost)" in the SUSv2 column means that most or all of the thread-related requirements of SUSv2 are implemented, but the platform has not been formally validated.
• "1003.1c" refers to the POSIX 1003.1c-1995 standard. (Part of 1003.1-1996.) Implementations of this standard are now common throughout the industry, and there's rarely any reason to rely on proprietary interfaces such as UI threads, DCE threads, or CMA. (Except where a version of a product must support older versions of a platform that supported only the proprietary interfaces.) The notation "(almost)" means that the basic part of the POSIX interface is there, and works, but if probing into poorly illuminated corners one must be prepared for the sudden appearance of monsters. The most common weakness is in the area of signal handling. OpenVMS lacks any equivalent concept, for example, and LinuxThreads behaves in substantially non-POSIX ways because each cloned "thread" is really an independent process.
• "DCE" refers to "DCE threads", a part of the Open Software Foundation's "Distributed Computing Environment". This was very loosely based on draft 4 of the document that eventually became POSIX 1003.1c-1995. (Some versions of AIX also used an interface based on draft 7 of the document. Neither should ever be called "POSIX threads", because there are more than enough substantial differences to make that extremely confusing to everyone. "Draft 7" has been called "AIX threads" in some contexts, as it was never implemented anywhere else.)
• "UI threads" refers to the SVR4.2MP "UI thread" extensions developed by Sun and codified into the UNIX System V "SVID" by the long-since defunct "UNIX International" body. To my knowledge, this interface is available only on Sun and UnixWare platforms.
• I'm not entirely certain how to categorize the Linux variants. It would be useful to "end users" to provide a listing by vendor and version (e.g., Red Hat Linux 6.0). Listing by Linux kernel version is almost useless as that has nothing to do with thread support. (Unless you're using "raw" clone calls.) Listing by LinuxThread version would be slightly more useful, except that's not the version buyers/downloaders see prominently, and therefore could also lead to confusion.