Smartphone Operating System (779883), страница 10
Текст из файла (страница 10)
To properly protect memory, we need to determine the rangeof addresses that a process or interrupt vector can use, protect memoryCOMPUTER STRUCTURES37outside the address range and ensure that nothing can run outside thecontrol of the operating system. Instead of setting up protection to keepother usages out, we set up protection to keep each process usage in.This is typically done in conjunction with hardware. When a particularpiece of code is executing, the operating system sets two registers: a baseregister holds the lowest address that can be used by the executing codeand a limit register holds the number of memory addresses that can beaddressed. Setting these registers is reserved only for the operating system;it does this through the use of privileged instructions. Working with theseregisters is part of the work of the operating system as it manipulatesprocesses to share the CPU.Protecting the CPUThe many programs that run at the same time on a computer share theCPU; this sharing includes the operating system.
As we structure theway that this sharing is done, we must make sure that the operatingsystem always gets control of the CPU back from a program – even if thatprogram has bugs or goes into an infinite loop.Consider what happens if we do not protect the CPU in this way.A program that gets into an infinite loop may never relinquish controlof execution and the computer would be frozen. If this happened on amobile phone while a conversation was going on, the phone would simplyfreeze and the conversation could not continue. Even worse, consider ifsystem code had a bug that caused a user program in privileged mode tostart writing to protected memory, corrupting operating system tables.To prevent this from happening, operating systems often use twoconcepts.
First, we can use a timer to cause an interrupt that transferscontrol back to the operating system. That timer is set when the programbegins using the CPU and interrupts the program’s execution after aspecific period has elapsed. While timers can be fixed, they are usuallycapable of using a variable time period. If an operating system uses avariable program timer then certain programs can run for longer thanothers. Note that timer interrupts can happen at any time and thatsometimes they happen at inconvenient times. For example, these timerinterrupts can be made during system calls, interrupting the kernel duringa system call service.A second way of protecting the operating system from freezing up isto combine the use of variable timers with a control concept of processorsharing.
This combination enables operating systems to implement concepts of process management, including time slices and context switches.38THE CHARACTER OF OPERATING SYSTEMSThere are many housekeeping details that must be done with timers. Forexample, consider the manipulation of the program timer. At each contextswitch, this timer must be reset for the next execution.
If the timer is avariable timer, then a new value must be derived for the next program’stime slice. This is quite probably in a table and should be looked up, butit provides a good example of the complex duties of the operating system.In addition, processes can voluntarily give up their time on the processorby yielding the processor to other processes.Keeping the Current TimeUsing timers to protect the CPU also provides operating systems with amechanism to keep the current time. If timer interrupts occur at regularintervals, we can compute the time of day based on the last accuratetime.However, this method is actually quite inaccurate. We must dependon the fact that there are no interrupts during a timer interrupt andthat servicing the timer interrupt itself is instantaneous.
Since theseassumptions are usually not correct, the system time starts to drift ifwe implement it this way. Operating systems typically use hardwaretime-of-day clocks to implement system time.Communication StructuresA fourth essential component of modern computers is communication.The structures that have been developed to handle communication issuesparallel very closely those that address I/O.
Communication is a specialcase of I/O and special attention – resulting in specialized APIs andoperating system structures – has been given to this area by operatingsystem designers. In some cases, for example Symbian OS, an operatingsystem has been developed around communication issues.At the lowest level, communication is raw binary data moving throughphysical I/O devices connected to a computer. As discussed above,operating systems take a variety of approaches to implementing deviceI/O and presenting the I/O interface to the other APIs.
In the variousimplementations of communication structures, operating systems treatthe physical communication devices as they would other I/O devices.On top of the physical I/O device, operating systems implement aninterface between software and hardware through the use of devicedrivers.DIFFERENT PLATFORMS39On top of the hardware–software interface, operating systems placea layer that allows users to use the hardware through the privilegedinstructions of the kernel. As we have seen earlier, there are many waysto manipulate communication hardware, from file-like interfaces in Linuxto file-server applications in Symbian OS. The implementation of thisaccess layer incorporates the design model of the operating system.Most communication requires protocols to be run through specificdevice interfaces.
A protocol is an exchange of data that follows aspecific prearranged format. There are many different ways of communicating through computer devices and these different ways follow differentprotocols. For example, one could pass a file between computers usinga TCP/IP local area network or using Bluetooth technology.
While theend result is the same – a file gets from one computer to another – theprotocols that are used to exchange that file’s data are very differentbetween the two media.With the advent of the Internet and the overwhelming use of TCP/IP,operating systems typically abstract away the details of communicationprotocols by implementing communication through an abstraction calleda socket.
A socket is a connection with two endpoints – two sides of thecommunication channel – with an implementation of a communicationprotocol in between. The abstraction of a socket works well because theprotocol implementation is hidden and the methods of data exchangeare kept the same, regardless of the protocol being implemented. So aprogram can use the write() system call to send data over a socket andnot be concerned about whether the socket is connected over TCP/IP orBluetooth.The idea of abstraction can play out further in a fashion similar to themodel of memory.
In this extended abstraction, each protocol is built onthe underlying services of the layer below. This ‘stack’ of communicationprotocols is nicely implemented as a stack of implementations, whereeach implementation represents a certain functionality and each onepasses its data to layers above or below. We discuss these issues furtherin Chapter 10.2.3 Different PlatformsWe have given an overview of the concepts and structures that characterize modern operating systems.
This section gives some examples of howthese concepts and structures are used in different implementations.40THE CHARACTER OF OPERATING SYSTEMSOS/360 and MVSThe IBM OS/360 line of mainframe computers was developed aheadof the operating systems that were to run on them.
Thus, the hardwareexisted while software developers were scrambling to get an operatingsystem that made that hardware useful to run. As operating systemsdeveloped for the 360 line, operating concepts were also evolving. Theoperating system grew over time as concepts of multiprogramming andmultitasking were developed.• The first version of OS/360 was the simplest: a sequential schedulercalled the primary control program (PCP). PCP performed only onetask at a time.
Control returned to the operating system only when thetask was completed. I/O was processed synchronously and causedprograms to stop while they waited for I/O to complete.• The next version of OS/360 introduced multiprogramming with a fixednumber of tasks (MFT). MFT could (eventually) run up to 15 tasks atonce and could reschedule tasks while they waited for (synchronous)I/O to complete.• The last version of OS/360 allowed a variable number of tasks tobe run concurrently – theoretically, any number could be concurrent.Multitasking with a variable number of tasks (MVT) also supportedrescheduling of synchronous I/O-bound tasks.• A new version of the operating system, the single virtual storage (SVS)version, was developed.
SVS implemented multitasking, but forced allprocesses to occupy the same memory space. Context-switching wasexpensive but memory protection was simple. The only memory thatcould be violated was the operating system memory, as all programsshared that space.• The most popular version of the operating system was called multiplevirtual storage (MVS). MVS put each process in its own address spacein memory, allowing memory to grow as needed by adding virtualmemory on the disk.
Memory protection was now more complicated,because process memory moved in and out of physical memory andmultiple applications could be resident in memory at the same time.MVS saw implementations in OS/370 and OS/390 for various incarnations of IBM mainframes. Notice how the concepts of multiprogrammingand multitasking evolved, carrying with them ideas of virtual memoryDIFFERENT PLATFORMS41and device I/O.
Memory-protection issues also evolved: protection wasa lot easier in PCP, where only one process ran at a time, than in MVS,where multiple processes were concurrent.Unix and LinuxAs we discussed in Chapter 1, Unix evolved from MULTICS and usedmany of its ideas. The character of Unix has a very loosely connectedfeel: all of its components build on each other through the use of fixedAPIs and its approach to software design is to build the operating systemby interconnecting simpler tools.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
