site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jul 24, 2006, at 6:55 PM, Guy Sherman wrote: Hi all, Many thanks in advance, Mac OS X Internals: A Systems Approach Amit Singh Addison-Wesley Professional ISBN 0321278542 http://people.freebsd.org/~julian/threads/ This includes a reference to the original Mach threads paper out of CMU. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I am currently studying operating systems at university and am doing an assignment based around investigating the differences between kernel threads and user threads. Anyhow, I need to be able to find what the theoretical maximum for my machine is. I am running the x86 version of OSX 10.4.7 Tiger. Guy Sherman In MacOS X, for each user space thread, there is a corresponding kernel (Mach) thread, either initially (if the thread is created suspended) or after all the setup is done (if the thread is created running). So MacOS X is technically a 1:1 (1 user thread per 1 kernel thread) threading model in its implementation details. Similar to most systems that support SMP scalability through multithreading, this is the least complicated approach to implement, which is likely why most people implementing threads tend to choose this path. If you want to see a N:1 (N user threads to 1 kernel thread) model, you can look at the threading in FreeBSD 4.3 or thereabouts, or you can look at liblwp in SunOS 4.1.3. There are also a number of preemptive single kernel thread scheduler packages in places like comp.unix.archives (e.g. "sigsched"), though to use them, you will either need to find an older BSD-based system, or you will need to convert the uses of "signal()" to "bsd_signal()", or use "sigaction()" and specify SA_RESTART in the flags so that system calls are automatically restarted, rather than returning EINTR when a signal is received. There are also a number of call conversion scheduler packages out there (i.e. trade a blocking call for a non-blocking call + a context switch). The DEC MTS ("Multi Threading Services") on VMS 5.X is a call conversion scheduler threads package written in Bliss that utilizes VMS asynchronous system traps (ASTs) as a means of triggering context switches. Similarly, you could also look up SA or "Scheduler Activations", which operates on a similar principle. There are also threads packages like "green threads", which are voluntary preemption, user space scheduling utilizing non-blocking I/O (same with "MIT pthreads"). Call conversion schedulers are typically backed by a single kernel thread (N:1), although with approaches like SA, this is not strictly required if you can support thread reentrancy per CPU in your scheduler, and have a way to start up a scheduler context (Sequent, for example, invented an "sfork()" system call for this, where almost everything in the process was shared, except the stack and the scheduler queue; the modern day equivalent is frequently called "rfork()" on systems that implement it). By far, the richest set of implementations you will find on one platform are the FreeBSD implementations in older versions of FreeBSD. For a long time, FreeBSD operated with an N:1 model, implemented an N:M (N user threads for M kernel threads, where N >= M), and at the same time supported a "linux threads" kernel module for Linux-like 1:1 threading. They now have a native 1:1 threading mode in one of their two standard threads libraries. If you want architectural details of MacOS X, you could do worse than to get the book: If you want threads-related information, well, there's a huge amount of information you can find with Google; here's a collection of threads resources put together by Julian Elischer as part of the FreeBSD threads library work: This email sent to site_archiver@lists.apple.com