Concepts with Symbian OS (Symbian Books), страница 10

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. In Unix, simpler is better.There are many examples of this design philosophy. Commands onUnix are quite simple and can be combined to build more complexcommands.

Files on Unix are not structures in any way but are consideredonly as a sequence of bytes, to be interpreted by individual applications.• The kernel is a monolithic kernel. Any changes to kernel operations – such as the change in serial-port implementation – requires achange in kernel source code and a recompilation and reinstallationof the entire kernel.• Unix is multitasking and supports multithreading. It supports configurable policies regarding scheduling of processes. Unix is a multi-usersystem, where multiple users can be accessing the same computerand sharing the resources.• Devices are implemented as files and access to devices is achieved byopening the file representation of a device.

Devices can be ‘opened’by multiple users for reading and by only one user for writing.• Unix uses virtual memory and uses memory mapping to avoid userapplications from accessing memory from other applications. Memorymapping automatically translates any memory reference into the areareserved for the process.• Unix supports many kinds of file systems and communication methods through implementations of dynamically loaded implementationmodules and device drivers.Linux is an open-source version of Unix. The fact that Linux is opensource has been both a blessing and a curse: allowing the source code tothe operating system to be shared has fostered much innovation but hasalso allowed people to exploit weaknesses.42THE CHARACTER OF OPERATING SYSTEMSSymbian OSSymbian OS is unique among operating systems in the sense that it wasdesigned from its inception3 with smartphones as the target platform.

Itis not a generic operating system shoehorned into a smartphone nor isit an adaptation of a larger operating system for a smaller platform. Aswe saw in Chapter 1, Symbian OS has a history of evolving design (fromSIBO to EPOC to Symbian OS) specifically targeted at smartphones for itsimplementation.The precursors to Symbian OS have given their best features. Theoperating system is object-oriented, inherited from EPOC. This meansthat systems calls involve system, or kernel-side, objects and that theidea of abstraction permeates system design. Where an operating systemsuch as Unix might create a file descriptor and use that descriptor as aparameter in an open call, Symbian OS would create an object of theRFile class and call the open() method tied to the object. In Unix, itis widely known that file descriptors are integers that index a table in theoperating system’s memory.