John said:
I want to know in concurrency perspective, what's the differences
between thread and task? I read the book and it says task is a thread
of execution. Does it mean task is a thread? A thread is a task?
When I was in school, a "task" was a process having exactly one thread.
Your book seems to be using the term "task" to mean "thread.
Every school and every operating system vendor seem to have different
definitions for thread, task, strand, lightweight process, etc. Below
is the set of working definitions I use. I currently write x86
firmware, but used to work on microprocessor design teams, so this
terminology may reflect the de facto standards used in industry, rather
than any pristinely codified standard to which your textbook refers.
A program is an ordered sequence of instructions to be executed by a
computer. A process is a program in execution, meaning some code has
been loaded in memory, and is intended to be interpreted by the computer
as a set of instructions. A particular ordering of the instructions,
determined at run-time, is called a "thread."
A single processor, if capable of "multitasking," can put the current
thread on ice periodically and begin executing another instead. This is
called a "context switch," where the "context" includes the current
instruction pointer and other register values. Eventually, the
processor will switch back to the original thread. This allows a single
processor to execute multiple threads without making any of them wait
until the others have run to completion.
Here's where things get tricky. It is possible for a computer to store
multiple contexts for a given program. In some parlances, each context
is said to represent a separate "process." This is the convention on
Linux. Elsewhere, all contexts associated with a particular in-memory
instance of a program are said to represent different "threads," all of
which are just parts of a single "process."
The dichotomy in terminology has to do with how different operating
systems are implemented. Some operating systems, like Windows, use
"process" to mean the entity represented by some heavyweight internal
data structure; threads through the same program are specifically not
considered separate processes. The reason is that the "process" data
structure in the OS represents much more than which program is being
executed. It includes lists of child processes, open file handles,
permission sets, and other goodies.
Other OSes, like Linux, use "process" to represent any thread of
execution, and "threads" on Linux are just processes that share a set of
code pages. Separate data structures describe which resources are
shared by any two processes. It's a flexible, high-performance way of
doing things, but it plays hell with the traditional notion of a process
tree.
Solaris has a particulary complicated set of definitions for this sort
of thing, which I never really understood.
