Context switch: Difference between revisions

Line 14:

| publisher = Prentice Hall

}}

</ref> This allows multiple processes to share a single [[central processing unit]] (CPU), and is an essential feature of a multiprogramming or [[multitasking operating system]]. In a traditional CPU, each process – a program in execution – uses the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously.<ref>Or sequentially so rapidly that they appear to be simultaneous.</ref> For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and loads the following running process is called a context switch.

</ref> This allows multiple processes to share a single [[central processing unit]] (CPU) and is an essential feature of a multiprogramming or [[multitasking operating system]]. In a traditional CPU, each process{{snd}} a program in execution{{snd}} uses the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously.<ref>Or sequentially so rapidly that they appear to be simultaneous.</ref> For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and loads the following running process is called a context switch.

The precise meaning of the phrase "context switch" varies. In a multitasking context, it refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an [[interrupt]], such as when a task needs to access [[disk storage]], freeing up CPU time for other tasks. Some operating systems also require a context switch to move between [[user mode]] and [[kernel mode]] tasks. The process of context switching can have a negative impact on system performance.<ref name="Tanenbaum2014">{{cite book |last1=Tanenbaum |first1=Andrew S. |last2=Bos |first2=Herbert |title=Modern Operating Systems |date=March 20, 2014 |publisher=Pearson |isbn=978-0133591620 |edition=4th |language=en}}</ref>{{rp|28}}

Line 52:

===No context switch needed===

Considering a general arithmetic addition operation A = B+1. The instruction is stored in the [[instruction register]] and the [[program counter]] is incremented. A and B are read from memory and are stored in registers R1, R2 respectively. In this case, B+1 is calculated and written in R1 as the final answer. This operation ~~as there are~~ sequential reads and writes and there's no waits for [[Subroutine|function calls]] used, hence no context switch/wait takes place in this case.

Considering a general arithmetic addition operation {{nobr|A {{=}} B + 1.}} The instruction is stored in the [[instruction register]], and the [[program counter]] is incremented. A and B are read from memory and are stored in registers R1, R2 respectively. In this case, {{nobr|B + 1}} is calculated and written in R1 as the final answer. This operation only requires sequential reads and writes, and there's no waits for [[Subroutine|function calls]] used, hence no context switch/wait takes place in this case.

===Context switch caused by interrupt===

Suppose a process A is running and a timer interrupt occurs. The user registers — program counter, stack pointer, and status register — of process A are then implicitly saved by the CPU onto the kernel stack of A. Then, the hardware switches to kernel mode and jumps into interrupt handler for the operating system to take over. Then the operating system calls the <code>switch()</code> routine to first save the general-purpose user registers of A onto A's kernel stack, then it saves A's current kernel register values into the PCB of A, restores kernel registers from the PCB of process B, and switches context, that is, changes kernel stack pointer to point to the kernel stack of process B. The operating system then returns from interrupt. The hardware then loads user registers from B's kernel stack, switches to user mode, and starts running process B from B's program counter. <ref name="OSTEP book"> {{cite book |last1=Arpaci-Dusseau |first1=Remzi |last2=Arpaci-Dusseau |first2=Andrea |year=2015 |url=http://pages.cs.wisc.edu/~remzi/OSTEP/ |title=Operating Systems: Three Easy Pieces |access-date=25 July 2016 |archive-date=25 July 2016 |archive-url=https://web.archive.org/web/20160725012948/http://pages.cs.wisc.edu/~remzi/OSTEP/ |url-status=live }}</ref>

Suppose a process A is running and a timer interrupt occurs. The user registers — program counter, stack pointer, and status register — of process A are then implicitly saved by the CPU onto the kernel stack of A. Then, the hardware switches to kernel mode and jumps into interrupt handler for the operating system to take over. Then the operating system calls the <code>switch()</code> routine to first save the general-purpose user registers of A onto A's kernel stack, then it saves A's current kernel register values into the PCB of A, restores kernel registers from the PCB of process B, and switches context, that is, changes kernel stack pointer to point to the kernel stack of process B. The operating system then returns from interrupt. The hardware then loads user registers from B's kernel stack, switches to user mode, and starts running process B from B's program counter.<ref name="OSTEP book"> {{cite book |last1=Arpaci-Dusseau |first1=Remzi |last2=Arpaci-Dusseau |first2=Andrea |year=2015 |url=http://pages.cs.wisc.edu/~remzi/OSTEP/ |title=Operating Systems: Three Easy Pieces |access-date=25 July 2016 |archive-date=25 July 2016 |archive-url=https://web.archive.org/web/20160725012948/http://pages.cs.wisc.edu/~remzi/OSTEP/ |url-status=live }}</ref>

== {{Anchor|LATENCY}}Performance ==

Line 78:

== See also ==

* [[Application checkpointing]]

* [[Latency (engineering)]]

@@ Line 14: / Line 14: @@
   | publisher = Prentice Hall
   }}
-</ref> This allows multiple processes to share a single [[central processing unit]] (CPU), and is an essential feature of a multiprogramming or  [[multitasking operating system]]. In a traditional CPU, each process – a program in execution – uses the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously.<ref>Or sequentially so rapidly that they appear to be simultaneous.</ref> For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and loads the following running process is called a context switch.
+</ref> This allows multiple processes to share a single [[central processing unit]] (CPU) and is an essential feature of a multiprogramming or  [[multitasking operating system]]. In a traditional CPU, each process{{snd}} a program in execution{{snd}} uses the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously.<ref>Or sequentially so rapidly that they appear to be simultaneous.</ref> For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and loads the following running process is called a context switch.
 The precise meaning of the phrase "context switch" varies. In a multitasking context, it refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an [[interrupt]], such as when a task needs to access [[disk storage]], freeing up CPU time for other tasks. Some operating systems also require a context switch to move between [[user mode]] and [[kernel mode]] tasks. The process of context switching can have a negative impact on system performance.<ref name="Tanenbaum2014">{{cite book |last1=Tanenbaum |first1=Andrew S. |last2=Bos |first2=Herbert |title=Modern Operating Systems |date=March 20, 2014 |publisher=Pearson |isbn=978-0133591620 |edition=4th |language=en}}</ref>{{rp|28}}
@@ Line 52: / Line 52: @@
 ===No context switch needed===
-Considering a general arithmetic addition operation A = B+1. The instruction is stored in the [[instruction register]] and the [[program counter]] is incremented. A and B are read from memory and are stored in registers R1, R2 respectively. In this case, B+1 is calculated and written in R1 as the final answer. This operation as there are sequential reads and writes and there's no waits for [[Subroutine|function calls]] used, hence no context switch/wait takes place in this case.
+Considering a general arithmetic addition operation {{nobr|A {{=}} B + 1.}} The instruction is stored in the [[instruction register]], and the [[program counter]] is incremented. A and B are read from memory and are stored in registers R1, R2 respectively. In this case, {{nobr|B + 1}} is calculated and written in R1 as the final answer. This operation only requires sequential reads and writes, and there's no waits for [[Subroutine|function calls]] used, hence no context switch/wait takes place in this case.
 ===Context switch caused by interrupt===
-Suppose a process A is running and a timer interrupt occurs. The user registers&nbsp;— program counter, stack pointer, and status register&nbsp;— of process A are then implicitly saved by the CPU onto the kernel stack of A. Then, the hardware switches to kernel mode and jumps into interrupt handler for the operating system to take over. Then the operating system calls the <code>switch()</code> routine to first save the general-purpose user registers of A onto A's kernel stack, then it saves A's current kernel register values into the PCB of A, restores kernel registers from the PCB of process B, and switches context, that is, changes kernel stack pointer to point to the kernel stack of process B. The operating system then returns from interrupt. The hardware then loads user registers from B's kernel stack, switches to user mode, and starts running process B from B's program counter. <ref name="OSTEP book"> {{cite book |last1=Arpaci-Dusseau |first1=Remzi |last2=Arpaci-Dusseau |first2=Andrea |year=2015 |url=http://pages.cs.wisc.edu/~remzi/OSTEP/ |title=Operating Systems: Three Easy Pieces |access-date=25 July 2016 |archive-date=25 July 2016 |archive-url=https://web.archive.org/web/20160725012948/http://pages.cs.wisc.edu/~remzi/OSTEP/ |url-status=live }}</ref>
+Suppose a process A is running and a timer interrupt occurs. The user registers&nbsp;— program counter, stack pointer, and status register&nbsp;— of process A are then implicitly saved by the CPU onto the kernel stack of A. Then, the hardware switches to kernel mode and jumps into interrupt handler for the operating system to take over. Then the operating system calls the <code>switch()</code> routine to first save the general-purpose user registers of A onto A's kernel stack, then it saves A's current kernel register values into the PCB of A, restores kernel registers from the PCB of process B, and switches context, that is, changes kernel stack pointer to point to the kernel stack of process B. The operating system then returns from interrupt. The hardware then loads user registers from B's kernel stack, switches to user mode, and starts running process B from B's program counter.<ref name="OSTEP book"> {{cite book |last1=Arpaci-Dusseau |first1=Remzi |last2=Arpaci-Dusseau |first2=Andrea |year=2015 |url=http://pages.cs.wisc.edu/~remzi/OSTEP/ |title=Operating Systems: Three Easy Pieces |access-date=25 July 2016 |archive-date=25 July 2016 |archive-url=https://web.archive.org/web/20160725012948/http://pages.cs.wisc.edu/~remzi/OSTEP/ |url-status=live }}</ref>
 == {{Anchor|LATENCY}}Performance ==
@@ Line 78: / Line 78: @@
 == See also ==
+* [[Application checkpointing]]
 * [[Latency (engineering)]]

Context switch: Difference between revisions

Navigation menu

Search