Re: Theoretical thread limit
Re: Theoretical thread limit
- Subject: Re: Theoretical thread limit
- From: Terry Lambert <email@hidden>
- Date: Tue, 25 Jul 2006 02:50:33 -0700
On Jul 24, 2006, at 6:55 PM, Guy Sherman wrote:
Hi all,
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.
Many thanks in advance,
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:
Mac OS X Internals: A Systems Approach
Amit Singh
Addison-Wesley Professional
ISBN 0321278542
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:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden