Subject: Re: [linux-audio-dev] thread background reading
From: Anders Torger (torger_AT_ludd.luth.se)
Date: Mon May 14 2001 - 21:32:40 EEST
On Monday 14 May 2001 17:31, you wrote:
> 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.
Saying "process" in that case was probably not wise, what I really meant was
"kernel thread". With stricter terminology I would say that a process is just
a container for a program and a term defined entirely separate from threads.
A process can have one or more kernel threads assigned to it, as well as user
threads. In Linux, all threads of a process are implemented as kernel threads
(the man page call them "kernel processes" though), with the benefit of
scalability over multiple processors, and the drawback of costly context
switches, meaning poor scalability in number of threads. A kernel thread
context switch within the same process is of course cheaper than a switch
between processes when the address space need to be changed, but still
significantly more expensive than a user thread context switch.
I can assure you that you cannot feasibly run a program of 1000 threads in
Linux (not using a user thread library). Scheduling becomes much to coarse if
many of them are active. (And your list of processes becomes very long)
/Anders Torger
This archive was generated by hypermail 2b28 : Mon May 14 2001 - 21:51:09 EEST