Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Operating system
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
====Interrupts==== {{Main|Interrupt}} An [[interrupt]] (also known as an [[Abort (computing)|abort]], [[Exception handling|exception]], ''fault'', [[Signal (IPC)|signal]],<ref name="lpi-ch20-p388_quote1">{{cite book | last = Kerrisk | first = Michael | title = The Linux Programming Interface | publisher = No Starch Press | year = 2010 | page = 388 | isbn = 978-1-59327-220-3 | quote = A signal is a notification to a process that an event has occurred. Signals are sometimes described as software interrupts. }}</ref> or ''trap'')<ref name="Hyde_1996">{{cite book |last1 = Hyde |first1 = Randall |chapter-url = https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |access-date = 22 December 2021 |date = 1996 |title = The Art Of Assembly Language Programming |chapter = Chapter Seventeen: Interrupts, Traps and Exceptions (Part 1) |publisher = No Starch Press |quote = The concept of an interrupt is something that has expanded in scope over the years. The 80x86 family has only added to the confusion surrounding interrupts by introducing the int (software interrupt) instruction. Indeed, different manufacturers have used terms like exceptions, faults, aborts, traps and interrupts to describe the phenomena this chapter discusses. Unfortunately there is no clear consensus as to the exact meaning of these terms. Different authors adopt different terms to their own use. |archive-date = 22 December 2021 |archive-url = https://web.archive.org/web/20211222205623/https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |url-status = live }}</ref> provides an efficient way for most operating systems to react to the environment. Interrupts cause the [[central processing unit]] (CPU) to have a [[control flow]] change away from the currently running program to an [[interrupt handler]], also known as an interrupt service routine (ISR).<ref name="sco-ch5-p308_a">{{cite book | last = Tanenbaum | first = Andrew S. | title = Structured Computer Organization, Third Edition | publisher = Prentice Hall | year = 1990 | page = [https://archive.org/details/structuredcomput00tane/page/308 308] | isbn = 978-0-13-854662-5 | url = https://archive.org/details/structuredcomput00tane/page/308 | quote = Like the trap, the interrupt stops the running program and transfers control to an interrupt handler, which performs some appropriate action. When finished, the interrupt handler returns control to the interrupted program. }}</ref><ref name="osc-ch2-p32_a">{{cite book | last = Silberschatz | first = Abraham | title = Operating System Concepts, Fourth Edition | publisher = Addison-Wesley | year = 1994 | page = 32 | isbn = 978-0-201-50480-4 | quote = When an interrupt (or trap) occurs, the hardware transfers control to the operating system. First, the operating system preserves the state of the CPU by storing registers and the program counter. Then, it determines which type of interrupt has occurred. For each type of interrupt, separate segments of code in the operating system determine what action should be taken.}}</ref> An interrupt service routine may cause the [[central processing unit]] (CPU) to have a [[context switch]].<ref name="osc-ch4-p105">{{cite book | last = Silberschatz | first = Abraham | title = Operating System Concepts, Fourth Edition | publisher = Addison-Wesley | year = 1994 | page = 105 | isbn = 978-0-201-50480-4 | quote = Switching the CPU to another process requires saving the state of the old process and loading the saved state for the new process. This task is known as a context switch.}}</ref>{{efn|Modern CPUs provide instructions (e.g. SYSENTER) to invoke selected kernel services without an interrupts. Visit https://wiki.osdev.org/SYSENTER for more information.}} The details of how a computer processes an interrupt vary from architecture to architecture, and the details of how interrupt service routines behave vary from operating system to operating system.<ref name="osc-ch2-p31">{{cite book | last = Silberschatz | first = Abraham | title = Operating System Concepts, Fourth Edition | publisher = Addison-Wesley | year = 1994 | page = 31 | isbn = 978-0-201-50480-4 }}</ref> However, several interrupt functions are common.<ref name="osc-ch2-p31"/> The architecture and operating system must:<ref name="osc-ch2-p31"/> # transfer control to an interrupt service routine. # save the state of the currently running process. # restore the state after the interrupt is serviced. =====Software interrupt===== A software interrupt is a message to a [[Process (computing)|process]] that an event has occurred.<ref name="lpi-ch20-p388_quote1"/> This contrasts with a ''hardware interrupt'' — which is a message to the [[central processing unit]] (CPU) that an event has occurred.<ref name="osc-ch2-p30">{{cite book | last = Silberschatz | first = Abraham | title = Operating System Concepts, Fourth Edition | publisher = Addison-Wesley | year = 1994 | page = 30 | isbn = 978-0-201-50480-4 | quote = Hardware may trigger an interrupt at any time by sending a signal to the CPU, usually by way of the system bus. }}</ref> Software interrupts are similar to hardware interrupts — there is a change away from the currently running process.<ref name="lpi-ch20-p388_quote2">{{cite book | last = Kerrisk | first = Michael | title = The Linux Programming Interface | publisher = No Starch Press | year = 2010 | page = 388 | isbn = 978-1-59327-220-3 | quote = Signals are analogous to hardware interrupts in that they interrupt the normal flow of execution of a program; in most cases, it is not possible to predict exactly when a signal will arrive. }}</ref> Similarly, both hardware and software interrupts execute an [[Interrupt handler|interrupt service routine]]. Software interrupts may be normally occurring events. It is expected that a [[Preemption (computing)#Time slice|time slice]] will occur, so the kernel will have to perform a [[context switch]].<ref name="lpi-ch20-p388_quote3">{{cite book | last = Kerrisk | first = Michael | title = The Linux Programming Interface | publisher = No Starch Press | year = 2010 | page = 388 | isbn = 978-1-59327-220-3 | quote = Among the types of events that cause the kernel to generate a signal for a process are the following: A software event occurred. For example, ... the process's CPU time limit was exceeded[.] }}</ref> A [[computer program]] may set a timer to go off after a few seconds in case too much data causes an algorithm to take too long.<ref name="lpi-ch20-p388">{{cite book | last = Kerrisk | first = Michael | title = The Linux Programming Interface | publisher = No Starch Press | year = 2010 | page = 388 | isbn = 978-1-59327-220-3 }}</ref> Software interrupts may be error conditions, such as a malformed [[machine code|machine instruction]].<ref name="lpi-ch20-p388"/> However, the most common error conditions are [[division by zero]] and [[segmentation fault|accessing an invalid memory address]].<ref name="lpi-ch20-p388"/> [[User (computing)|Users]] can send messages to the kernel to modify the behavior of a currently running process.<ref name="lpi-ch20-p388"/> For example, in the [[Command-line interface|command-line environment]], pressing the ''interrupt character'' (usually [[Control-C]]) might terminate the currently running process.<ref name="lpi-ch20-p388"/> To generate ''software interrupts'' for [[x86]] CPUs, the [[INT (x86 instruction)|INT]] [[assembly language]] instruction is available.<ref name="intel-developer">{{cite web |url=https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf |access-date=2022-05-05 |title=Intel® 64 and IA-32 Architectures Software Developer's Manual |volume=2 |date=September 2016 |publisher=[[Intel Corporation]] |page=610 |archive-date=23 March 2022 |archive-url=https://web.archive.org/web/20220323231921/https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf |url-status=live }}</ref> The syntax is <code>INT X</code>, where <code>X</code> is the offset number (in [[hexadecimal]] format) to the [[interrupt vector table]]. =====Signal===== To generate ''software interrupts'' in [[Unix-like]] operating systems, the <code>kill(pid,signum)</code> [[system call]] will send a [[Signal (IPC)|signal]] to another process.<ref name="duos-p200">{{cite book | last = Bach | first = Maurice J. | title = The Design of the UNIX Operating System | publisher = Prentice-Hall | year = 1986 | page = 200 | isbn = 0-13-201799-7 }}</ref> <code>pid</code> is the [[process identifier]] of the receiving process. <code>signum</code> is the signal number (in [[mnemonic]] format){{efn|Examples include [[Signal (IPC)#SIGINT|SIGINT]], [[SIGSEGV]], and [[SIGBUS]].}} to be sent. (The abrasive name of <code>kill</code> was chosen because early implementations only terminated the process.)<ref name="lpi-ch20-p400">{{cite book | last = Kerrisk | first = Michael | title = The Linux Programming Interface | publisher = No Starch Press | year = 2010 | page = 400 | isbn = 978-1-59327-220-3 }}</ref> In Unix-like operating systems, ''signals'' inform processes of the occurrence of asynchronous events.<ref name="duos-p200"/> To communicate asynchronously, interrupts are required.<ref name="sco-ch5-p308_b">{{cite book | last = Tanenbaum | first = Andrew S. | title = Structured Computer Organization, Third Edition | publisher = Prentice Hall | year = 1990 | page = [https://archive.org/details/structuredcomput00tane/page/308 308] | isbn = 978-0-13-854662-5 | url = https://archive.org/details/structuredcomput00tane/page/308 }}</ref> One reason a process needs to asynchronously communicate to another process solves a variation of the classic [[Readers–writers problem|reader/writer problem]].<ref name="osc-p182">{{cite book | last = Silberschatz | first = Abraham | title = Operating System Concepts, Fourth Edition | publisher = Addison-Wesley | year = 1994 | page = 182 | isbn = 978-0-201-50480-4 }}</ref> The writer receives a pipe from the [[Shell (computing)|shell]] for its output to be sent to the reader's input stream.<ref name="usp-ch6-p153">{{cite book | last1 = Haviland | first1 = Keith | last2 = Salama | first2 = Ben | title = UNIX System Programming | publisher = Addison-Wesley Publishing Company | year = 1987 | page = 153 | isbn = 0-201-12919-1 }}</ref> The [[Command-line interface|command-line]] syntax is <code>alpha | bravo</code>. <code>alpha</code> will write to the pipe when its computation is ready and then sleep in the wait queue.<ref name="usp-ch6-p148">{{cite book | last1 = Haviland | first1 = Keith | last2 = Salama | first2 = Ben | title = UNIX System Programming | publisher = Addison-Wesley Publishing Company | year = 1987 | page = 148 | isbn = 0-201-12919-1 }}</ref> <code>bravo</code> will then be moved to the [[Multilevel feedback queue|ready queue]] and soon will read from its input stream.<ref name="usp-ch6-p149">{{cite book | last1 = Haviland | first1 = Keith | last2 = Salama | first2 = Ben | title = UNIX System Programming | publisher = Addison-Wesley Publishing Company | year = 1987 | page = 149 | isbn = 0-201-12919-1 }}</ref> The kernel will generate ''software interrupts'' to coordinate the piping.<ref name="usp-ch6-p149"/> ''Signals'' may be classified into 7 categories.<ref name="duos-p200"/> The categories are: # when a process finishes normally. # when a process has an error exception. # when a process runs out of a system resource. # when a process executes an illegal instruction. # when a process sets an alarm event. # when a process is aborted from the keyboard. # when a process has a tracing alert for debugging. =====Hardware interrupt===== [[Input/output]] (I/O) [[Peripheral|devices]] are slower than the CPU. Therefore, it would slow down the computer if the CPU had to [[Busy waiting|wait]] for each I/O to finish. Instead, a computer may implement interrupts for I/O completion, avoiding the need for [[Polling (computer science)|polling]] or busy waiting.<ref name="sco-ch5-p292">{{cite book | last = Tanenbaum | first = Andrew S. | title = Structured Computer Organization, Third Edition | publisher = Prentice Hall | year = 1990 | page = [https://archive.org/details/structuredcomput00tane/page/292 292] | isbn = 978-0-13-854662-5 | url = https://archive.org/details/structuredcomput00tane/page/292 }}</ref> Some computers require an interrupt for each character or word, costing a significant amount of CPU time. [[Direct memory access]] (DMA) is an architecture feature to allow devices to bypass the CPU and access [[random-access memory|main memory]] directly.<ref name=A22-6821-7-storage>{{cite book |author = IBM |title = IBM System/360 Principles of Operation |date = September 1968 |version = Eighth Edition |url = http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf |section = Main Storage |section-url = http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf#page=8 |mode = cs2 |page = 7 |access-date = 13 April 2022 |archive-date = 19 March 2022 |archive-url = https://web.archive.org/web/20220319083255/http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf |url-status = live }}</ref> (Separate from the architecture, a device may perform direct memory access{{efn|often in the form of a DMA chip for smaller systems and I/O channels for larger systems}} to and from main memory either directly or via a bus.)<ref name="sco-ch5-p294"> {{cite book | last = Tanenbaum | first = Andrew S. | title = Structured Computer Organization, Third Edition | publisher = Prentice Hall | year = 1990 | page = [https://archive.org/details/structuredcomput00tane/page/294 294] | isbn = 978-0-13-854662-5 | url = https://archive.org/details/structuredcomput00tane/page/294 }}</ref>{{efn|Modern [[motherboard]]s have a DMA controller. Additionally, a device may also have one. Visit [[SCSI RDMA Protocol]].}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)