Subject: [linux-audio-dev] thread background reading
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun May 13 2001 - 19:42:59 EEST
>When talking about threads, it is worth noting that Linux implements threads
>as processes, while more advanced (==complex) operating systems like Solaris
>(or Windows 2000) automatically chooses between starting a new kernel thread
>to hold the new thread, or run it more lightweightedly within the same kernel
>thread. This way a single process can hold 1000 threads without any problems,
>while a Linux program with more than 20 threads starts to behave really
>poorly due to costly context switches. I cannot see why an audio application
>would need 1000, or even 20 threads though. Server software for enterprise
>environments may benefit from it though (a thread per client).
some readers here may not be familiar with the varieties of threads. a
quick summary:
* an execution context is a set of registers and an address space
* a thread is an execution context plus an instruction stream.
* user-space threads:
* data structures for managing threads exist 100% in user space
* thread scheduler is a user-space entity.
* thread switches don't involve kernel operations, and don't
alter "deep" h/w like the the TLB. switches are therefore
very fast and cheap.
* the scheduler has no clue that a thread has blocked in a kernel
operation, so if a thread is blocked during disk i/o, the entire
process is stopped until that thread resumes.
* kernel-space threads
* data structures for managing threads exist primarily in the kernel
* thread scheduler is either the process scheduler or very closely
integrated with it.
* thread switches involve the entire processor state, and are thus
costlier.
* the scheduler knows when a thread is blocked by the kernel, and
so can effectively schedule another thread (perhaps from the same
process) on the processor.
You may ask "isn't there some way to get the best of both worlds?" the
answer is yes, and it was the subject of both a couple of PhD theses
and some fairly arduous technical work. the general name for the most
widely used design is "scheduler activations", and the basic idea is
to have the kernel "activate" the user-space scheduler of a process
when a thread in that process blocks. Solaris has support for SA,
though Mach was the first real OS in which they were operated. If you
want to know more about SA, search by name, or look for papers by Tom
Anderson. If you want to know what was involved in implementing them
under Mach, look for "Adding Scheduler Activations to Mach 3.0" by
Barton-Davis, MacNamee, Vaswani and Lazowska. Yes, that's me. And now
you know why I think about this stuff so much :)
--p
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 19:56:42 EEST