Concepts with Symbian OS (779878), страница 7
Текст из файла (страница 7)
They typically do very little on their own, but insteadwait for interrupts to drive them to do their varied tasks. Operatingsystems have many services that can be used and many ways to usethese services, but only offer them in response to requests. So operatingsystems have their own system of ‘interrupt vectors’ and these ‘vectors’are implemented using system calls into software implementations. Uponreceipt of an interrupt, an operating system stops what it was doing,saving the spot for its return, and finds a software implementation toservice that interrupt. When the interrupt service routine has completed,the operating system returns to where it left off.Interrupts make a great notification system, but sometimes notificationsneed to be turned off or ignored. This is facilitated in operating systemsby masking.
This terminology comes from the idea of using a bitstring torepresent all possible interrupts. By constructing a second bitstring with1s representing the interrupts to be enabled, this second bitstring can beANDed with the bitstring of interrupts to produce only those interruptswhich are enabled and functioning. This operation of masking is used toturn interrupts on and off. (In other situations, where a mask of bits is notused, the operation is still called masking.) Turning interrupts off allowsthe operating system to handle higher-priority interrupts without beingdistracted by other – probably lower-priority – interrupts.This model of interrupt-driven operation is so useful that softwareinterrupts have been worked into operating systems just like hardwareinterrupts. Software interrupts take several forms. There are interrupts thatare triggered when errors occur (for example, reading beyond the endof a file), interrupts that cause the operating system to do certain things(for example, when a system timer goes off), and interrupts that have noestablished service routines (these are usually set up and driven by specificsoftware applications).
Interrupts can be sent explicitly (for example, Unixallows ‘signals’ to be sent to the operating system through special systemcalls) or they can be generated transparently by making function calls(many Symbian OS system calls generate software interrupts).Since operating systems are passive software systems, there must bea way to get them started listening for and servicing interrupts. Thisis typically done by a bootstrap program in a fixed storage location.The computer’s hardware is designed to find this program and start itsexecution.
The bootstrap program is usually quite small and is designedto locate and start a much larger program. This second program is theoperating system implementation. The bootstrap program is usually storedCOMPUTER STRUCTURES25in read-only memory (ROM) supplied with the computer system. Thesecond program, or the kernel, is the system that sets up the computingenvironment and waits for interrupts to occur.ProcessesThe programs that run on a computer also work with the interrupt system.In modern operating systems, several programs execute at once, sharingthe computing resources.
These concurrent programs are called processesonce they begin running on the CPU. Obviously, if a single process ranto completion before another began to operate, a computer would runextremely slowly. Instead, processes run at the same time and rely oninterrupts to stop their execution, returning control to the operatingsystem. The scheduler is the part of the operating system responsible fordeciding which process should next execute on the CPU.An operating system that allows multiple processes to run in thismanner is said to support multitasking.
Multitasking shares the CPUaccording to policies developed by the operating system designers andperhaps the operating system users. One such policy is the time periodfor which a program uses the CPU, called a time slice. Note that it almostcertainly takes more than a single time slice for a program to executeto completion, since the period of time is in the order of milliseconds.This means that there are several programs, each using the processor fora time slice and each suspended while the operating system allows otherprograms to share the processor. This procedure of moving processes intoand out of execution on the CPU is called a context switch; there is muchhousekeeping to be done during each switch that provides each programa context in which to run.Operating systems may also support multithreading.
Multithreadingis different from multitasking in that multiple threads of control executewithin the memory space of a single process. Multitasking refers toswitching between processes; multithreading occurs within a specificprocess. Threads provide for code execution in a lighter form than withprocesses. For example, context-switching between threads uses a similarconcept to that of switching between processes but is quicker sincecontext information about the memory space does not need to change.Device I/OA computer system without devices is not very useful. How an operatingsystem implements communication with a device is important for many26THE CHARACTER OF OPERATING SYSTEMSreasons – including the performance of the computer and the ease withwhich it is programmed.
From the previous section, we already know thatdevice I/O is driven by interrupts, but exactly how those interrupts aregenerated and serviced determine how efficient the operating system is.The general sequence of servicing I/O requests is depicted in Figure 2.5.The request made by an application is fielded by the operating systemthrough one of its APIs.
The operating system uses the device driverspecific to the device being accessed and passes the request on to thehardware device (note that operating system interrupts are not neededto pass this data on). The hardware receives the request and servicesit, passing the results back up through the system. The device interruptsthe operating system through the device driver and the operating systemdelivers the results to the application.Notice that the scenario depicted in Figure 2.5 requires a lot ofwaiting. While the operating system is working with the application’srequest, the application is waiting for it to be completed.
This is notunusual; application programs typically wait for devices. However, if theoperating system were to wait for the results from the device, no otheroperating system duties would be performed. All other activities in thecomputer would therefore wait as well.Consider an example in which an application tries to send a textmessage. After setting up the message data, the application initiates theApplication requestOperating systemDevice driverInterrupt vectorHardware data transferTimeFigure 2.5 The control pathway for synchronous device I/OCOMPUTER STRUCTURES27transfer by signaling the mobile phone device to transfer the message.This request goes through an operating system API, which communicatesthrough this level to the device driver and on to the hardware to sendthe message.
It might be acceptable for the application to wait until themessage is sent. However, if the operating system was forced to wait forthe message, it would have to suspend all other services. That wouldmean that alarms would not be displayed and incoming phone callswould be ignored. If the message took a lengthy period of time to send,the phone would just freeze up until the message was finally on its way.Obviously, this is not a good situation.The method of device communication that waits through the communication cycle is called synchronous communication.
Synchronouscommunication causes all stages in the process to wait. This type ofcommunication is good for real-time systems, where the system is dedicated to I/O and processing of received data, but not very useful forgeneral-purpose systems.Most general-purpose I/O is asynchronous. That is, other operationscan continue while waiting for I/O to complete. An I/O sequence likethat in Figure 2.6 must occur.The hardware should signal that the transfer has begun and signalagain when the results of the I/O request are in.
Using this method, theoperating system is free to process other requests and the applicationApplication requestOperating systemDevice driverInterrupt vectorHardwaredata transferTimeFigure 2.6The control pathway for asynchronous device I/O28THE CHARACTER OF OPERATING SYSTEMScan even go on to do other things. (Often this method of I/O is best forapplications that must work with a graphical user interface, which mustusually be updated as the data request is being processed.)The use of asynchronous device I/O means that an operating systemmust keep track of the state of devices. If the operating system is going to‘get back’ to handling a device after it has serviced an I/O request, it hasto keep track of what was happening with that device and where it waswhen it last worked with it.
This record-keeping function of an operatingsystem is a very important one, one that keeps an operating system busymuch of the time and one that potentially takes up a lot of the memoryneeded to run an operating system.In the quest to minimize the involvement of the operating system indevice I/O, more I/O functionality can be placed on the device withthe addition of more interrupts to enable communication. Taken to anextreme, a device could do all I/O by itself, filling a specific area inshared memory with data and signaling the operating system only whendata transfer is complete. This method of I/O is called direct memoryaccess (DMA) and is extremely useful in freeing up operating systemand application time.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
