Embedded Linux questions

[Thomas Mondoshawan Tate]

--WplhKdTI2c8ulnbP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 02, 2001 at 06:23:45AM -0700, Alan Dayley wrote:
> At 01:02 PM 11/1/01 -0700, you wrote:
> >Sounds similar to what I do in game development, though rarely do I need=
 to
> >access low level hardware to do task switching. Generally I'd just spawn=
 a
> >bunch of threads, one for each task, and use IPC to handle information
> >passing. I suppose you could call the code that controls those threads a
> >"kernel", though I try to stay away from that word, since it's far too o=
ften
> >confused with the OS kernel.
> >
> >I'm doubtful you'll need to do low level task switching -- ever --
> >since doing so would be disastrous, and would totally nullify any reason=
 for
> >using Linux in the first place. =3Dop
>=20
> OK.  Perhaps this is something I need to learn better and I have asked th=
e=20
> wrong question.
>=20
> - What is the difference between a "task" and a "thread"?  Or, put anothe=
r=20
> way, what is the difference between "task switching" and "thread=20
> switching"?  The way you phrased things seems to indicate a difference,=
=20
> that task switching is lower level, if you will, than switching threads.

When I refer to a "task", I'm referring to the raw memory data, CPU
regisers, stacks, and metadata associated with a program in memory.

A "process" is a task or thread that is treated as a task and will require
a task switch to run.

A "thread" is a copy of a task that uses exactly the same memory space as
it's parent task, but it has different CPU registers, stacks and metadata,
and is controlled by the parent task. As such, to the scheduler, a thread is
considered a separate process, and will automaticially run concurrently to
the controlling task.

The process of task switching is exactly as you said: the CPU's current Task
State Segment (TSS) is stored in a protected area of memory, and the next
TSS is loaded. Each TSS stores information about a program's memory space,
what it's used for, and whatever else metadata Linux needs to know about
(the aforementioned metadata, CPU registers, and stack memory locations).
The hard, time consuming part of this is the disabling of IRQs, and
reloading of the Local (memory) Descriptor Table (LDT). Since this is
_always_ managed by the scheduler and memory manager in the Linux kernel, y=
ou
won't ever need to touch this -- doing so is fatal.

What I meant by the above is that I'd never have to go down to the CPU
hardware to initiate a task switch myself -- the Linux kernel does that for
me. All I have to do is synchronize data between the subthreads and the main
task.

A good example of this is XMMS. When it's runnning, you'll see four or five
instances of xmms in the listing of a 'ps ax' command. Those other instances
are the threads of the program -- all running concurrently, and each doing a
different job.

Good sources of information relating to this are the fork(), exec(),
execv(), execve() function calls, and the POSIX threads (pthreads) section
in the glibc info pages.

> - What would be the latency for "thread" switching?  Faster than task=20
> switching?  Are CPU time slices based on threads or tasks?

Since threads and tasks are both considered as separate processes to the
Linux scheduler, they both require a task switch, and thus, have the same
latency issues.

> >Might want to send a few questions to the linux-kernel list about this
> >project since they're ear-deep in the kernel's internals daily and would
> >know more about these kinds of issues than most of us PLUGer's. =3Dop
>=20
> Yes, I will do that if I need too.  It is great to keep this conversation=
=20
> local for now!  Besides, PLUG-devel needs the traffic.

Agreed. =3Do)

--=20
Thomas "Mondoshawan" Tate
phoenix@psy.ed.asu.edu
http://tank.dyndns.org

--WplhKdTI2c8ulnbP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE74sYsYp5mUsPGjjwRAineAJ4nDkTlGvdFFdXUXV/Hzni5OlNErwCgvFYu
9Cy+2pq2PbUzZOS760Wsxv0=
=1UOx
-----END PGP SIGNATURE-----

--WplhKdTI2c8ulnbP--