Difference between revisions of "Thread"
(An OK start) |
(Kernel threads; threads usually have stacks) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The term '''thread''' does not have a generally accepted firm/strict definition, but it generally means an [[instruction]] [[execute|execution]] locus which is less powerful (in terms of its capabilities) than a [[process]]; e.g. a thread will generally not have its own [[address space]]. | The term '''thread''' does not have a generally accepted firm/strict definition, but it generally means an [[instruction]] [[execute|execution]] locus which is less powerful (in terms of its capabilities) than a [[process]]; e.g. a thread will generally not have its own [[address space]]. | ||
| − | Threads are usually instantiated within a process, and share its [[memory]], [[input/output|I/O]] channels, etc. | + | Threads are usually instantiated within a process, and share its [[memory]], [[input/output|I/O]] channels, etc. Threads do seem to usually have individual, per-thread, [[stack]]s, so that a thread can cease executing while down a [[subroutine call]] chain, and later resume executing at the exact point where it paused. (Thread-like abstractions without stacks are sometimes called '''fibers'''.) |
| + | |||
| + | All the threads in a particular process exhibit [[fate-sharing]]: if the process is terminated, all the threads within it necessarily are also lost. | ||
| + | |||
| + | Threads are often, but not always, supported by the [[kernel]] of an [[operating system]]; e.g. the system's [[scheduler]] may be prepared to run threads. If not, a [[library]] included in the process may manage them. | ||
In [[multi-processor]] systems where the kernel supports threads, it may be allowed for multiple threads in a single process to execute concurrently. | In [[multi-processor]] systems where the kernel supports threads, it may be allowed for multiple threads in a single process to execute concurrently. | ||
| + | |||
| + | Threads may also exist as abstractions inside the kernel (named '''kernel threads'''), for use in structuring of work inside the kernel. | ||
{{semi-stub}} | {{semi-stub}} | ||
| + | |||
| + | ==See also== | ||
| + | |||
| + | * [[Kernel process]] | ||
| + | |||
| + | [[Category: OS Basics]] | ||
Latest revision as of 18:25, 15 December 2023
The term thread does not have a generally accepted firm/strict definition, but it generally means an instruction execution locus which is less powerful (in terms of its capabilities) than a process; e.g. a thread will generally not have its own address space.
Threads are usually instantiated within a process, and share its memory, I/O channels, etc. Threads do seem to usually have individual, per-thread, stacks, so that a thread can cease executing while down a subroutine call chain, and later resume executing at the exact point where it paused. (Thread-like abstractions without stacks are sometimes called fibers.)
All the threads in a particular process exhibit fate-sharing: if the process is terminated, all the threads within it necessarily are also lost.
Threads are often, but not always, supported by the kernel of an operating system; e.g. the system's scheduler may be prepared to run threads. If not, a library included in the process may manage them.
In multi-processor systems where the kernel supports threads, it may be allowed for multiple threads in a single process to execute concurrently.
Threads may also exist as abstractions inside the kernel (named kernel threads), for use in structuring of work inside the kernel.
