Subject: Re: [linux-audio-dev] thread background reading
From: D. Stimits (stimits_AT_idcomm.com)
Date: Mon May 14 2001 - 18:31:15 EEST
Paul Davis wrote:
>
> >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).
Something to add about threads on Linux, and "...Linux implements
threads as processes..." myth. Linux does NOT implement threads as
processes, though they do not comply with POSIX because they each have
their own PID. The underlying thread IS a thread, not a separate process
(the clone command is not the same as a fork, you are jumping to
conclusions when you see the separate PID). It sounds more like a
discussion of various thread models MxN, Mx1, and 1x1 is being confused.
The performance penalty isn't as bad as it sounds for context switching;
even processes get context switched because they are preempted,
something you have to live with in multitasking systems. More likely the
performance penalties you've seen or heard of in the past were due to
cache thrashing or other design problems.
D. Stimits, stimits_AT_idcomm.com
>
> 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 : Mon May 14 2001 - 18:49:56 EEST