What Is Darwin (and How it Powers Mac OS X)

There are two distinct but related things here. One is multiprocessing which brings genuine concurrency and the other is the implementation of user-level threading models as a means of having multiple process-like entities that share address spaces. The locking granularity of the kernel will affect the scalability of all concurrency, whether it be normal or lightweight processes that call into the kernel. The effort for multiprocessing in Mach itself was put into place very many years ago, but the various modern free BSD systems started much later at making parts of their kernel safe to schedule on multiple processors. This is why XNU which is derived from Mach and pieces of various BSDs has had to essentially duplicate the same efforts of the other free BSD derivatives in increasing the granularity of the BSD kernel code. This is a complicated process and it takes time and care, and can be difficult to maintain in general.

The other matter is the manner in which user-level threads are mapped to kernel entities that can be scheduled concurrently.

You have your pure user-level N:1 threads, where the threading library schedules multiple threads within one process. This doesn’t require any special kernel support, but it also doesn’t provide any concurrency for executing the threads in a process. Thread creation and switching is really fast, but there are caveats with regard to calling into the kernel unless you add the requisite complexity to intercept and manage syscalls. This is how thread libraries on BSD, Carbon, and Linux (before linuxthreads) typically worked.

You can have 1:1 threads, where each user-level thread is mapped to an entity that the kernel can schedule concurrently. Thread creation and switching can often be most expensive. This the the model many systems use when they don’t just provide the previous implementation strategy, and there are scalability concerns with using a lot of threads in this manner. That’s partly why thread pooling was popular when Java didn’t have nio, because mapping a lot of Java threads directly to 1:1 threads could seriously impede scalability. A naive implementation (like say linuxthreads or NPTL) of threading with clone or rfork_thread, or XNU’s implementation of pthreads on Mach threads will provide such a model.

Then there are N:M systems, which attempt to minimize the cost associated with creating and switching threads (found in 1:1 systems) while providing concurrency (so as to not suffer the caveats of N:1 systems). This can be accomplished in a number of ways, and you can find a lot of interesting papers to read about various implementations and their performance properties. Many commercial unices offer M:N systems (such as Solaris), and have been the development goal of FreeBSD (KSE) and NetBSD (schedular activations). The implementation of an N:M system is much more complicated (multiple schedulars that optimally should communicate), but can have performance advantages depending on the nature of the work involved. It doesn’t improve security, it’s not inferior to a 1:1 model, and it’s certainly not the source of scalability problems with XNU (because it doesn’t use it for one) and it didn’t obtain it from other BSDs.

NPTL in Linux had a lot of purposes, though it wasn’t to alter the mapping of user and kernel threads. LinuxThreads had various limitations (hard limits), conformancy problems, and performance problems stemming from implementation strategies (manager threads for instance).

forking is not a replacement for threading; if you’re not using a shared address space why you’re using multiple threads is beyond me. Since the problem with XNU threads isn’t that they’re scheduled in userland (since they aren’t) this affords you nothing.

Mach isn’t an especially high-performance kernel to begin with, and secondly the conversion of the BSD subsystem into a thread-safe entity is an ongoing process. Since most threads for the OS X desktop user will either not be performance-critical or will be compute-bound rather than syscall-bound this matters rather little to them, and Apple will improve as is necessary. As a normal server operating system, though, this poses a number of problems if you’re performance-bound, because you’ll be spending a lot of time in the BSD subsection for networking, disk I/O, and so forth. This is true whether you use threads or not.