Threads: Difference between revisions
pc>Yuron No edit summary |
 W81054ch [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
-->{{Path|Processes|5}}<!-- | -->{{Path|Processes|5}}<!-- | ||
-->{{#invoke:Dependencies|add|Processes,4|Multi Threading,5}} | -->{{#invoke:Dependencies|add|Processes,4|Multi Threading,5}} | ||
A thread of execution is a single, sequential series of machine | A thread of execution is a single, sequential series of machine instructions (or lines of code if you prefer to think at a more | ||
instructions (or lines of code if you prefer to think at a more | |||
abstract level). | abstract level). | ||
Threads are basically similar to <em>[[processes]]</em> (and are | Threads are basically similar to <em>[[processes]]</em> (and are sometimes called “lightweight processes”). Threads belong | ||
sometimes called “lightweight processes”). Threads belong | <em>within</em> processes. The simple model is to have one thread in each process (in which case the term “thread” becomes | ||
<em>within</em> processes. The simple model is to have one thread in each | redundant) but any process could have multiple threads. Threads share <em>most</em> of their [[context]] although they will each have some <strong>private</strong> data space such as processor <strong>registers</strong> and their own <strong>stack</strong>. | ||
process (in which case the term “thread” becomes | |||
redundant) but any process could have multiple threads. Threads share | |||
<em>most</em> of their [[context]] although they will each have some | |||
<strong>private</strong> data space such as processor <strong>registers</strong> and their own <strong>stack</strong>. | |||
[[Image:thread_process.png|link=|alt=Threads and processes]] | [[Image:thread_process.png|link=|alt=Threads and processes]] | ||
| Line 24: | Line 19: | ||
*switching threads within the same process is considerably cheaper (faster) than switching processes because there is (much) less <em>context</em> to <em>switch</em>. | *switching threads within the same process is considerably cheaper (faster) than switching processes because there is (much) less <em>context</em> to <em>switch</em>. | ||
Perhaps unsurprisingly, it is also faster to create or destroy a | Perhaps unsurprisingly, it is also faster to create or destroy a thread than to create or destroy a process. | ||
thread than to create or destroy a process. | |||
---- | ---- | ||
==== Thread management ==== | ==== Thread management ==== | ||
Threads may be managed by the operating system [[scheduler]] | Threads may be managed by the operating system [[scheduler]] or, at user level, by a separate scheduler in the application. (Or both!) In Java (and possibly elsewhere) threads scheduled within the application ([https://en.wikipedia.org/wiki/Java_virtual_machine JVM]) are referred to as “[https://en.wikipedia.org/wiki/Green_threads green threads]”; those in the operating system (when available) are “native threads”. | ||
or, at user level, by a separate scheduler in the application. (Or | |||
both!) In Java (and possibly elsewhere) threads scheduled within the | |||
application | |||
([https://en.wikipedia.org/wiki/Java_virtual_machine JVM]) are | |||
referred to as “[https://en.wikipedia.org/wiki/Green_threads green threads]”; those in the operating system (when available) are “native threads”. | |||
Just like processes, each thread has its own [[Process_States|state]]: | Just like processes, each thread has its own [[Process_States|state]]: {running, ready or blocked}. | ||
{running, ready or blocked}. | |||
[[Image:thread_layers.png|link=|alt=Thread layers]] | [[Image:thread_layers.png|link=|alt=Thread layers]] | ||
Thread management by a user typically allows faster thread switching | Thread management by a user typically allows faster thread switching (no need for (slow) [[System_Calls|system calls]]) and the scheduling can be tailored to the application, with more predictable behaviour. On the other hand these probably need to use [https://en.wikipedia.org/wiki/Cooperative_multitasking <strong>cooperative scheduling</strong>] which relies on all the threads being ‘well behaved’; for example if one thread makes a system call which blocks, all the threads (in that process) will be blocked, even if others could (in principle) continue; thus there might be an unnecessary (and expensive) <em>process</em> context switch. | ||
(no need for (slow) [[System_Calls|system calls]]) and the scheduling | |||
can be tailored to the application, with more predictable behaviour. | |||
On the other hand these probably need to use [https://en.wikipedia.org/wiki/Cooperative_multitasking <strong>cooperative scheduling</strong>] | |||
which relies on all the threads being ‘well behaved’; for | |||
example if one thread makes a system call which blocks, all the | |||
threads (in that process) will be blocked, even if others could (in | |||
principle) continue; thus there might be an unnecessary (and | |||
expensive) <em>process</em> context switch. | |||
A potential disadvantage in managing threads at user-level is that it | A potential disadvantage in managing threads at user-level is that it requires its own management software for creating, tracking, switching, synchronising, destroying threads. This may be in the form of an imported library. | ||
requires its own management software for creating, tracking, | |||
switching, synchronising, destroying threads. This may be in the form | |||
of an imported library. | |||
Thread management by the operating system allows threads to be | Thread management by the operating system allows threads to be scheduled in a similar fashion to any process. Context switching (within the same process) can be cheaper than process switching but is still likely to be more expensive than leaving it to the application. | ||
scheduled in a similar fashion to any process. Context switching | |||
(within the same process) can be cheaper than process switching but is | |||
still likely to be more expensive than leaving it to the application. | |||
If you want to look at some pros and cons of the different strategies, have a look at the literature such as [https://www.geeksforgeeks.org/green-vs-native-threads-and-deprecated-methods-in-java/ this] or [http://wiki.c2.com/?GreenVsNativeThreads this]. | If you want to look at some pros and cons of the different strategies, have a look at the literature such as [https://www.geeksforgeeks.org/green-vs-native-threads-and-deprecated-methods-in-java/ this] or [http://wiki.c2.com/?GreenVsNativeThreads this]. | ||
| Line 65: | Line 39: | ||
==== Exercise ==== | ==== Exercise ==== | ||
There is an [[Exercises:Java_Threads|exercise]] to gain some familiarity | There is an [[Exercises:Java_Threads|exercise]] to gain some familiarity with Java threads. | ||
with Java threads. | |||
---- | ---- | ||
| Line 77: | Line 50: | ||
High performance hardware may support threads directly. | High performance hardware may support threads directly. | ||
<blockquote> | <blockquote> | ||
Partly this is a pragmatic attempt to harness more processing from | Partly this is a pragmatic attempt to harness more processing from the processor. One approach is to be able to thread-switch very quickly, making it worthwhile when one thread is blocked for even a short time (such as a cache miss). This will require extra registers to hold the appropriate threads’ context. Another approach is to have hardware which runs multiple threads genuinely concurrently (“Simultaneous Multithreading” (SMT)). “[https://en.wikipedia.org/wiki/Hyper-threading Hyper-Threading]” | ||
the processor. One approach is to be able to thread-switch very | is an Intel term for one version of this, of which you may have heard mention. | ||
quickly, making it worthwhile when one thread is blocked for even a | |||
short time (such as a cache miss). This will require extra | |||
registers to hold the appropriate threads’ context. Another | |||
approach is to have hardware which runs multiple threads genuinely | |||
concurrently (“Simultaneous Multithreading” (SMT)). | |||
“[https://en.wikipedia.org/wiki/Hyper-threading Hyper-Threading]” | |||
is an Intel term for one version of this, of which you may have | |||
heard mention. | |||
</blockquote> | </blockquote> | ||
In such cases the operating system will <em>need</em> to become involved in | In such cases the operating system will <em>need</em> to become involved in the thread scheduling. | ||
the thread scheduling. | |||
---- | ---- | ||
{{BookChapter|4|160-197}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Concepts}} | {{Category|Concepts}} | ||
{{Category|Deadlock}} | {{Category|Deadlock}} | ||
{{Category|Processes}} | {{Category|Processes}} | ||
Latest revision as of 10:03, 5 August 2019
| On path: Processes | 1: Processes • 2: Context • 3: Process Control Block (PCB) • 4: Multi Threading • 5: Threads • 6: Interprocess Communication • 7: Process Scheduling • 8: Scheduler • 9: Process States • 10: Process Priority |
|---|
| Depends on | Processes • Multi Threading |
|---|
A thread of execution is a single, sequential series of machine instructions (or lines of code if you prefer to think at a more abstract level).
Threads are basically similar to processes (and are sometimes called “lightweight processes”). Threads belong within processes. The simple model is to have one thread in each process (in which case the term “thread” becomes redundant) but any process could have multiple threads. Threads share most of their context although they will each have some private data space such as processor registers and their own stack.
Differences between processes and threads:
- threads within the same process share access to resources such as peripheral devices and files.
- threads within the same process share a virtual memory map.
- switching threads within the same process is considerably cheaper (faster) than switching processes because there is (much) less context to switch.
Perhaps unsurprisingly, it is also faster to create or destroy a thread than to create or destroy a process.
Thread management
Threads may be managed by the operating system scheduler or, at user level, by a separate scheduler in the application. (Or both!) In Java (and possibly elsewhere) threads scheduled within the application (JVM) are referred to as “green threads”; those in the operating system (when available) are “native threads”.
Just like processes, each thread has its own state: {running, ready or blocked}.
Thread management by a user typically allows faster thread switching (no need for (slow) system calls) and the scheduling can be tailored to the application, with more predictable behaviour. On the other hand these probably need to use cooperative scheduling which relies on all the threads being ‘well behaved’; for example if one thread makes a system call which blocks, all the threads (in that process) will be blocked, even if others could (in principle) continue; thus there might be an unnecessary (and expensive) process context switch.
A potential disadvantage in managing threads at user-level is that it requires its own management software for creating, tracking, switching, synchronising, destroying threads. This may be in the form of an imported library.
Thread management by the operating system allows threads to be scheduled in a similar fashion to any process. Context switching (within the same process) can be cheaper than process switching but is still likely to be more expensive than leaving it to the application.
If you want to look at some pros and cons of the different strategies, have a look at the literature such as this or this.
Exercise
There is an exercise to gain some familiarity with Java threads.
Examples
- Java supports threading as part of the language. Indeed – behind the scenes – it probably relies on it in the “system”, for example. In a simple system these may be scheduled by the Java Virtual Machine (JVM) software; more contemporary systems probably get help from the OS too. Here’s (yet) another article which may help explain this.
- Pthreads (POSIX threads) provide a standardised, language independent thread model for Unix(-like) systems.
High performance hardware may support threads directly.
Partly this is a pragmatic attempt to harness more processing from the processor. One approach is to be able to thread-switch very quickly, making it worthwhile when one thread is blocked for even a short time (such as a cache miss). This will require extra registers to hold the appropriate threads’ context. Another approach is to have hardware which runs multiple threads genuinely concurrently (“Simultaneous Multithreading” (SMT)). “Hyper-Threading” is an Intel term for one version of this, of which you may have heard mention.
In such cases the operating system will need to become involved in the thread scheduling.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 4, pages 160-197 |
|---|
