Re: thread versus task
- From: Jeffrey Schwab <jeff@xxxxxxxxxxxxxxxx>
- Date: Sat, 28 Oct 2006 19:39:30 GMT
John wrote:
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. :)
.
- References:
- thread versus task
- From: John
- thread versus task
- Prev by Date: weird CopyOnWriteArraySet error
- Next by Date: Re: memory usage of java
- Previous by thread: Re: thread versus task
- Next by thread: mozilla and firefox problem - JSP
- Index(es):
Relevant Pages
|
