Operating Systems

144 Operating Systems 144.1 144.2 144.3 144.4 144.5

Introduction ...................................................................................... Architectures of Operating Systems ................................................ Functions of Operating Systems ...................................................... Real-Time Operating Systems .......................................................... Conclusions ......................................................................................

Yingxu Wang Theoretical and Empirical Software Engineering Research Centre, University of Calgary, Canada

An operating system is a type of system software that manages and controls the resources and computing capability of a computer or a computer network, and provides users a logical interface for accessing the physical computer to execute applications. This chapter describes typical architectures and generic functions of operating systems. Section 1 introduces the basic concept and brief history of operating system technologies. Section 2 describes the conceptual and typical commercial architectures of operating systems. Section 3 presents the common functions of operating systems, such as process and thread management, memory management, file system management, I/O system management, and network/communication management. Real-time operating systems are described in Section 4 with illustrations of the RTOS+ operating system.

144.1 Introduction Operating system technologies have evolved from rather simple notions of managing the hardware on behalf of a single user or sequentially scheduled users to multiuser time-sharing systems and then to networked and distributed systems. Most modern operating systems are based on multi-programmed timesharing technologies [Brinch-Hansen, 1971; Peterson and Silberschantz, 1985; Silberschatz et al., 2003; Tanenbaum, 2001]. An operating system is a type of system software that manages and controls the resources and computing capability of a computer or a computer network, and provides users a logical interface for accessing the physical computer to execute applications. Almost all general-purpose computers need an operating system before any specific application may be installed and executed by users. The role of an operating system as a conceptual model of a physical computer is shown in Fig. 144.1.

Applications Operating system

Hardware (The naked machine)

(System software) (Application software)

Fig. 144.1 The role of an operating system in a general-purpose computer

1

Operating systems have evolved from being one-of-a-kind programs useful for only one type of hardware configuration to being portable programs that can be made to operate in a homogeneous family of hardware configurations and even in heterogeneous hardware platforms. The first operating system that operated on several different kinds of hardware configurations supporting many different kinds of devices was called OS/360. OS/360 was developed by IBM in the early 1960s as a computing platform for commercial applications. OS/360 enabled, for the first time, the support of different generations of hardware devices in a continuous manner, without having to modify the software that ran in the systems and avoiding the creation of completely new operating systems to accommodate new devices. The layered structure of operating systems was first proposed by Dijkstra in his THE multiprogramming system [Dijkstra, 1968]. The first commercial operating system, IBM VM/370, was developed in 1968. The first operating system to operate in a wide variety of hardware platforms was Unix, introduced by AT&T Bell Laboratories in the mid-1970s as a computing platform for research and development of engineering applications [Earhart, 1986]. Unix adopted the multitasking operating system technology, by which users may have several different kinds of concurrent activities to make better use of time and resources while getting work done. Unix had the characteristic that its size was small, and thus it could operate in inexpensive computers used for small groups of people. The first operating system to be used massively was MS-DOS, introduced by Microsoft in the early 1980s as a computing platform for personal or individual use [Microsoft, 1986]. The general-purpose operating systems can be classified into four types: the batch systems, time-sharing systems, real-time systems, and distributed systems. A batch system is an early type of operating systems that runs similar jobs sorted by an operator as a batch through an operation console. A time-sharing system is a type of multitasking operating systems that executes multiple jobs by automatically switching among them with predefined time slice. A real-time operating system is a type of special-purpose operating systems that is designed for dealing with highly time-constraint events of I/Os and processes for control systems. A distributed operating system is a type of operating systems that supports networking, communication, and file sharing among multiple computers via a network protocol [Sloane, 1993; Tanenbaum, 1994].

144.2 Architectures of Operating Systems The architectures of operating systems have evolved over the years from being a monolithic set of system services whose boundaries were difficult to establish to being a structured set of system services. Today, for example, some of these services, like the file system in charge of administering the file data stored by users, have boundaries, or software interfaces, that are standards regulated by organizations that are not related to any computer vendor. This modularization of operating systems into well-understood components provides the possibility to “mix and match” components from different vendors in one system. This trend toward pluggable system parts is accelerating with the formation of various consortia whose charters are to specify common, appropriate, and widely accepted interfaces for various system services. Current operating systems are all based on the idea of building higher-level hardware abstraction from lowerlevel hardware-oriented functions. In other words, current operating systems build higher-level abstractions from lower-level functions that are closer to the raw hardware. Thus, all kinds of hard disks, for example, are made to look and operate in the same manner by their low-level device drivers. Then, in turn, the operating system presents, with all other services in the system (such as the file system), a uniform, common view of a hard disk. This process of successive layers of abstraction is also followed within other services [Dijkstra, 1968]. In file systems, for example, a layer providing the abstraction of continuous storage that does not have device boundaries is built from the abstraction provided by the individual storage in several disks. 144.2.1 The Generic Architecture of Operating Systems An operating system may be perceived as an agent between the hardware and computing resources of a computer or a computer network and the applications and users as shown in Fig.144.2. A generic operating system may be divided into two parts: the kernel and the resource management subsystems [Peterson and Silberschantz, 1985; Silberschatz et al., 2003; and Tanenbaum, 2001]. The former is a set of central components for computing, including CPU scheduling and process management. The latter is a set of individual supporting software for various system resources and user interfaces.

2

Applications

Memory management

File system management

Communication management

Network management

I/O system management

Operating system kernel Process management

CPU scheduling

Hardware

Fig.144.2 The generic architecture of operating systems

The kernel is the most basic set of computing functions needed for an operating system. The kernel contains the interrupt handler, the task manager, and the interprocess communication manager. It may also contain the virtual memory manager and the network subsystem manager. With these services the system can operate all the hardware present in the system and also coordinate the activities between tasks. The services provided by an operating system can be organized in categories. Four possible categories are task control, file manipulation, device control, and information maintenance. 144.2.2 The Unix and Linux Operating Systems The history of Unix goes back to 1969 based on Ken Thompson, Dennis Ritchie and others’ work [Thomas et al., 1986]. The name "Unix" was intended as a pun on Multics (UNiplexed Information and Computing System). The development of Unix was essentially confined to Bell Labs for DEC's PDP-11 (16 bits) and later VAXen (32 bits) [Earhart, 1986]. But much happened to Unix outside AT&T, especially at Berkeley [CSRG, 1986]. Major vendors of workstations, such as SUN’s NFS, also contributed much to this development. Applications (Users)

Shells & commands

Compilers

Interpreters

Terminal signal handling

File system

Character I/O system

Swapping block I/O system

Terminal drivers

Disk and tape drivers

System libraries

Interface to kernel

CPU scheduling

Demand paging

Page replacement

Virtual memory

the kernel

Terminal controllers

Terminals

Device controllers

Memory controllers

Disks and tapes

Physical memory

Fig. 144.3 The architecture of Unix

3

The architecture of Unix is shown in Fig.144.3, which can be divided into the kernel and the system programs. The Unix kernel consists of system resource management, interfaces, and device drivers, such as the CPU scheduling, file system, memory management, and I/O management. Linux is a complete Unix clone for Intel 386/486/Pentium machines [Siever et al., 2003]. Linux is an operating system, which acts as a communication service between the hardware and the software of a computer system. The Linux kernel contains all of the features that one would expect in any operating system. Some of the features included are: • • • • • •

Multitasking (a technique for sharing a single processor between several independent jobs) Virtual Memory (allows repetitive, extended use of the computer's RAM for performance enhancement) Fast TCP/IP Drivers (for speedy communication) Shared Libraries (enable applications to share common code) Multi-user Capability (this means hundreds of people can use the computer at the same time, either over a network, the Internet, or on laptops/computers or terminals connected to the serial ports of those computers). Protected Mode (allows programs to access physical memory, and protects stability of the system)

144.2.3 The Windows XP Operating System Windows XP is a multitasking operating system built on enhanced technologies that integrate the strengths of Windows 2000 such as standard-based security, manageability and reliability, with the best features of Windows 98 and Windows Me such as plug and play, and easy-to-use user interfaces. The architecture of Windows XP is shown in Fig.144.4. Windows XP adopts a layered structure that consists of the hardware abstraction layer, the kernel layer, the executive layer, the user mode layer, and applications. Applications

Win32 subsystem User mode

I/O manager

Object manager

Security monitor

Process manager

Window manager

File system Cache manager

Plug & play manager

System call

Virtual memory manager

Graphic device drivers

Executive Device drivers Network drivers

Kernel Hardware abstraction layer

System hardware

Fig. 144.4 The architecture of Windows XP

Each kernel entity of Windows XP is treated as an object that is managed by an object manager in the executive. The kernel objects can be called by the user-mode applications via an object handle in a process. The use of kernel objects to provide basic services, and the support of client-server computing, enable Windows XP to support a wide variety of applications. Windows XP also provides virtual memory, integrated caching, preemptive scheduling, stronger security mode, and internationalization features.

4

144.3 Functions of Operating Systems The basic functions of operating systems can be classified as process and thread management, memory management, file system management, I/O system management, and network/communication management. This section describes the fundamental technologies of main operating system functions in modern operating systems. 144.3.1 Process Management A process is an execution of a program on a computer under the support of an operating system. A process can be a system process or a user process. The former executes system code, and the latter runs a user’s application. Processes may be executed sequentially or concurrently depending on the type of operating systems. The operating system carries out process management by the following activities: • Detection of process requests • Creation of processes by individual process control blocks (PCBs) • Allocation of system resources to processes, such as CPU time, memory, files, and I/O devices • Scheduling of processes based on a predefined process state transition diagram • Termination of processes A typical process state transition diagram of a real-time operating system, RTOS+ [Wang and Ngolah, 2003], is shown in Fig. 144.7. Threads are an important concept of process management in operating systems [Anderson et al., 1989; Lewis and Berg, 1998]. A thread is a basic unit of CPU utilization, or a flow of control within a process, supported by a thread control block (TCB) with a thread ID, a program counter, a set of registers, and a stack. Conventional operating systems are single thread systems. Multithreaded systems enable a process to control a number of execution threads. The benefits of multithreaded operating system and multithreaded programming are responsiveness, resource sharing, implementation efficiency, and utilization of multiprocessor architectures of modern computers. 144.3.2 CPU Scheduling CPU scheduling is a fundamental operating system function to maximize CPU utilization. The techniques of multiprogram and multithread are introduced to keep the CPU running different processes or threads on a timesharing basis. CPU scheduling is the basis of multiprogrammed and multithreaded operating systems [BrinchHansen, 1971]. • CPU scheduler: The CPU scheduler is a kernel function of operating systems that selects which process in the ready queue should be run next based on a predefined scheduling algorithm or strategy. • CPU dispatcher: The CPU dispatcher is a kernel function of operating systems that switches control of the CPU to the process selected by the scheduler. The typical CPU scheduling algorithms are described as follows: • First-come-first-served (FCFS) scheduling: This algorithm schedules the first process in the ready queue to the CPU based on the assumption that all processes in the queue have an equal priority. FCFS is the simplest scheduling algorithm for CPU scheduling. The disadvantage of the FCFS algorithm is that if there are long processes in front of the queue, short processes may have to wait for a very long time. • Shortest-job-first (SJF) scheduling: This algorithm gives priority to the short processes, which results in the optimal average waiting time. But the predication of process length seems a difficult issue by using the SJF strategy. • Priority (PR) scheduling: This algorithm assigns different priorities to individual processes. Based on this, CPU scheduling will be carried out by selecting the process with the highest priority. The drawback of the

5

priority algorithm is starvation, a term that denotes the indefinite blocking of low priority processes under high CPU load. To deal with starvation, the ageing technique may be adopted that increases the priority levels of low priority processes periodically, so that the executing priorities of those processes will be increased automatically while waiting in the ready queue. • Round-robin (RR) scheduling: This algorithm allocates the CPU to the first process in the FIFO ready queue for only a predefined time slice, and then it is put back at the tail of the ready queue if it has not yet completed. • Multiprocessor scheduling: This algorithm schedules each processor individually in a multiprocessor operating system on the basis of a common queue of processes. In a multiprocessor operating system, processes that need to use a specific device have to be switched to the right processor that is physically connected to the device. 144.3.3 Memory Management Memory management is one of the key functions of operating systems because memory is both the working space and storage of data or files. Common memory management technologies of operating systems are contiguous allocation, paging, segmentation, and combinations of these methods [Silberschatz et al., 2003]. • Contiguous memory allocation: This method is used primarily in a batch system where memory is divided into a number of fixed-sized partitions. The contiguous allocation of memory may be carried out by searching a set of holes (free partitions) that best fit the memory requirement of a process. A number of algorithms and strategies were developed for contiguous memory allocation such as the first-fit, best-fit, and worst-fit algorithms [Tanenbaum and Tanenbaum, 2001]. • Paging: Paging is a dynamic memory allocation method that divides the logical memory into equal blocks known as pages corresponding to physical memory frames. In a paging system, each logical address contains a page number and a page offset. The physical address is generated via a page table where the base address of an available page is provided. Paging technology is used widely in modern operating systems to avoid the fragmentation problem as found in the early contiguous memory allocation techniques. • Segmentation: This is a memory-management technique that uses a set of segments (logical address spaces) to represent user’s logical view of memory independent of the physical allocation of system memory. Segments can be accessed by providing their names (numbers) and offsets. • Virtual memory: When the memory requirement of a process is larger than physical memory, an advanced technique needs to be adopted known as the virtual memory, which enables the execution of processes that may not be completely in memory. The main approach to implement virtual memory is to separate the logical view of system memory from its physical allocation and limitations. Various technologies have been developed to support virtual memory such as the demand paging and demand segmentation algorithms [Silberschatz et al., 2003]. In memory-sharing systems, the sender and receiver use a common area of memory to place the data that is to be exchanged. To guarantee appropriate concurrent manipulation of these shared areas, the operating system has to provide synchronization services for mutual exclusion. A common synchronization primitive is the semaphore, which provides mutual exclusion for two tasks using a common area of memory. In a shared memory system the virtual memory subsystem must also collaborate to provide the shared areas of work. 144.3.4 File System Management File system is the most used functions of operating systems for non-programming users. A file is a logical storage unit of data or code separated from its physical implementation and location. Types of files can be text, source code, executable code, object code, word processor formatted, or system library code. The attributes of files can be identified by name, type, location (path of directory), size, date/time, user ID, and access control information. Logical file structures can be classified as sequential and random files. The former are files that organize information as a list of ordered records; while the latter are files with fixed-length logical records accessible by its block number.

6

Typical file operations are reading, writing, and appending. Common file management operations are creating, deleting, opening, closing, copying, and renaming. The file system of an operating system consists of a set of files and a directory structure that organizes all files and provides detailed information about them. The major function of file management system is to map logical files onto physical storage devices such as disks or tapes. Most file systems organize files by a tree-structured directory. A file in the file system can be identified by its name and detailed attributes provided by the file directory. The most frequently used method for directory management is the hash table. Although it is fast and efficient, backup is always required to recover a hash table from unpredicted damage. A physical file system can be implemented by contiguous, linked, and indexed allocation. Contiguous allocation can suffer from external fragmentation. Direct-access is inefficient with linked allocation. Indexed allocation may require substantial overheads for its index block. 144.3.5 I/O System Management I/O devices of a computer system encompass a variety of generic and special hardware and interfaces. Typical I/O devices that an operating system deals with are shown in Table 144.1. Table 144.1 Types of I/O Devices Types of I/O devices

Examples

System devices

System clock, timer, interrupt controller

Storage devices

Disks, CD drivers, tapes

Human interface devices

Keyboard, monitor, mouse

Communication devices

Serial/parallel buses, network cards, DMA controllers, MODEMs

Special devices

Application-specific control devices

I/O devices are connected to the computer through buses with specific ports or I/O addresses. Usually, between an I/O device and the bus, there is a device controller and an associated device driver program. The I/O management system of an operating system is designed to enable users to use and access system I/O devices seamlessly, harmoniously, and efficiently. I/O management techniques of operating systems can be described as follows: • Polling: Polling is a simple I/O control technique by which the operating system periodically checks the status of the device until it is ready before any I/O operation is carried out. • Interrupt: Interrupt is an advanced I/O control technique that lets the I/O device or control equipment notifies the CPU or system interrupt controller whenever an I/O request is occurred or a waiting event is ready. When an interrupt is detected, the operating system saves the current execution environment, dispatches a corresponding interrupt handler to process the required interrupt, and then returns to the interrupted program. Interrupts can be divided into different priorities on the basis of processor structures in order to handle complicated and concurrent interrupt requests. • DMA: Direct memory access (DMA) is used to transfer a batch of large amount of data between the CPU and I/O devices, such as disks or communication ports. A DMA controller is handled by the operating system to carry out a DMA data transfer between an I/O device and the CPU. • Network sockets: Most operating systems use a socket interface to control network communications. When requested in networking, the operating system creates a local socket and asks the target machine to be connected to establish a remote socket. Then, the pair of computers may communicate by a given communication protocol.

7

144.3.6 Communication Management A fundamental characteristic that may vary from system to system is the manner of communication between tasks. The two manners in which this is done are via messages sent between tasks or via the sharing of memory where the communicating tasks can both access the data. Operating systems can support either. In fact, both manners can coexist in a system. In message-passing systems, the sender task builds a message in an area that it owns and then contacts the operating system to send the message to the recipient. There must be a location mechanism in the system so that the sender can identify the receiver. The operating system is then put in charge of delivering the message to the recipient. To minimize the overhead of the message delivery process, some systems try to avoid copying the message from the sender to the kernel and then to the receiver, but to provide means by which the receiver can read the message directly from where the sender wrote it. This mechanism requires the operating system intervenes if the sender wants to modify the contents of a message before the recipient has gone through its content. In memory-sharing systems, the sender and receiver use a common area of memory to place the data that is to be exchanged. To guarantee appropriate concurrent manipulation of these shared areas, the operating system has to provide synchronization services for mutual exclusion. A common synchronization primitive is the semaphore, which provides mutual exclusion for two tasks using a common area of memory. In a shared memory system, the virtual memory subsystem must also collaborate to provide the shared areas of work. There are systems in which the amount of data that can be shared or sent between tasks is minimal. In the original Unix, for example, different tasks would not have shared memory, and only a very limited form of message passing was provided. The messages were constrained to be event notification. In this environment, data shared by processes have to be written into a common file. To support file sharing, some systems provide a locking service that is used to synchronize accesses to files by different tasks. The ISO open systems interconnection (OSI) reference model was developed in 1983 [Day and Zimmermann, 1983] for standardizing data communication protocols between different computer systems and networks. The OSI reference model is an important protocol framework for regulating multi-vendor multi-OS computers interconnection in local area network (LAN) and wide area network (WAN) environments [Stallings, 2000]. From bottom-up, the seven layers are: physical, data link, network, transport, session, presentation, and application as shown in Fig.144.5. • The physical layer: This layer provides a real communication channel for transmitting bit stream data. Mechanical, electrical and procedural interfaces for different physical transmission media are specified on this layer. • The data link layer: This layer implements data frames in the sender end and acknowledges frames in the receiver end, and provides retransmission mechanisms when a frame is not successfully transmitted. The data link layer converts a raw transmission line on the physical layer into a line that is free of transmission errors to the network layer. • The network layer: This layer controls the operation of a subnet by determining how message packets are routed from source to destination. It also provides congestion control, information flow counting, and packet size conversion between different networks. • The transport layer: This layer accepts data from the session layer, splits it up into smaller units for adapting to the network layer, and provides an interface between the session layer and the different implementations of the lower layer protocol and hardware. • The session layer: This layer provides transport session establishment, synchronization, and data flow control between different machines modeled by the transport layer. • The presentation layer: This layer converts the original data represented in vendor-dependent format into an abstract data structure at the sender end and vice versa at the receiver end. The presentation layer enables data to be compressed or encoded for transmitting on the lower layers.

8

• The application layer: This layer adapts a variety of terminals into a unified network virtual terminal interface for transferring different files between various file systems. OSI Application

TCP/IP Telnet

FTP

NFS

Presentation

DNS etc.

Session Transport

TCP

Network

UDP IP

Data link Physical Fig.144.5 The OSI reference model and TCP/IP

Fig.144.5 also contrasts the functional equivalency between the OSI model and TCP/IP [Day and Zimmermann, 1983]. The TCP/IP design philosophy [Comer, 1996/2000] was to provide universal connectivity, with connectionindependent protocols at the network layer. Thus TCP/IP does not address the data link and physical layers which determine the communication channels. There are no separate application, presentation, and session layers in TCP/IP; instead, a combined application layer is provided in TCP/IP, which has the functions of those layers. The IP protocol is approximately equivalent to the OSI network layer. In a WAN, IP is presented on every node in the network. The role of IP is to segment messages into packets (up to 64 kbyte) and then route and pass the packets from one node to another until they reach their destinations. IP uses packet switching as its fundamental transmission algorithm. A message is transmitted from gateway to gateway by dynamic routed packets. IP routes packets to their destination network, but final delivery is left to TCP. The TCP protocol fulfils the role of the OSI transport layer, plus some of the functionality of the session layer. TCP is designed to provide end-to-end connectivity. TCP is not required for packet routing, so it is not included on gateways. TCP provides an acknowledgement mechanism to enable messages to be sent from destination(s) back to the sender to verify receipt of each packet that makes up a message. 144.3.7 Network Management A network operating system implements protocols that are required for network communication and provides a variety of additional services to users and application programs. Network operating systems may provide support for several different protocols known as stacks, e.g. a TCP/IP stack and an IPX/SPX stack. A modern network operating system provides a socket facility to help users to plug-in utilities that provide additional services. Common services that a modern network operating system can provide include: • File services: File services transfer programs and data files from one computer on the network to another. • Message services: Message services allow users and applications to pass messages from one computer to another on the network. The most familiar application of message services is Email and intercomputer talk facilities. • Security and network management services: These services provide security across the network and allow users to manage and control the network.

9

• Printer services: Printer services enable sharing of expensive printer resources in a network. Print requests from applications are redirected by the operating system to a network workstation, which manages the requested printer. • Remote procedure calls (RPCs): RPCs provide application program interface services to allow a program to access local or remote network operating system functions. • Remote processing services: These services allow users or applications to remotely log in to another system on the network and use its facilities for program execution. The most familiar service of this type is Telnet, which is included in the TCP/IP protocol suite [Comer, 1996/2000] and many other modern network operating systems.

144.4 Real-Time Operating Systems A real-time operating system (RTOS) is essential to implement embedded and/or real-time control systems. An RTOS is an operating system that guarantees timely processing of external and internal events of real-time systems. Problems often faced by RTOS's are CPU and tasks scheduling, timing/event management, and resource management. RTOS requires multitasking, process threads, and explicit interrupt levels to deal with real-time events and interrupts. There were varying models of real-time operating systems developed in the last decades [Labrosse, 1999; Laplante, 1977; Liu, 2000]. The existing real-time operating systems are target-machine-specific, implementationdependent, and not formally described. Therefore, they are usually not portable as a generic real-time operating system to be seamlessly incorporated into real-time or embedded system solutions. An extended RTOS, RTOS+, is described in this section to address the above issues [Wang and Ngolah, 2003]. RTOS+ is a portable and multitask/multithread operating system capable of handling event-, time-, and interruptdriven processes in a real-time environment. RTOS+ is also specified by real-time process algebra (RTPA), a formal specification language for real-time architectures and behaviors description, particularly for the explicit description of the dynamic behaviors of real-time software systems [Wang, 2002/2003]. 144.4.1 The Architecture of RTOS+ The architecture of RTOS+ is described as shown in Fig.144.6, where interactions between system resources, components, and internal control models are illustrated. There are four subsystems in RTOS+: a) the processor and task scheduler, b) the resource controller, c) the event handler, and d) the system resources. The task scheduler is the innermost operating system kernel that directly controls the CPU and all other system resources by system control blocks. The resources of RTOS+, supplement to the CPU, are mainly the memory, system clock, I/O ports, interrupt facilities, files, and internal control models such as queues and task/resource control blocks as shown in Fig. 144.6. The task scheduling of RTOS+ is priority-based. We use a fixed-priority scheduling algorithm where the priority of a task is assigned based on its importance when it is created. Tasks are categorized into four priority types: the high and low priority interrupts, as well as the base and high priority processes. A process, when created, will be put into a proper queue corresponding to its predefined priority levels.

10

WaitingQH

ReadyQH

WaitingQL

ReadyQL

Running Process PCB SuspendedQ

DelayedQ

InterruptedQ

CompletedQ

Resource Control Bus

System Control Block

RTOS Task Scheduler

Processor

System Clock

Resource Bus

Interrupts

Event Low

Event High

Interrupt Low

Time-out

Interrupt High

Event Bus

I/Os

Memory

Files

Fig. 144.6 The architecture of RTOS+

144.4.2 The Task Scheduler of RTOS+ The Task Scheduler is the kernel of RTOS+. Its behaviors can be modeled by a state transition diagram as shown in Fig. 144.7. The task scheduler of RTOS+ is designed for handling event-, time-, and interrupt-driven processes, in which the CPU is allocated by a fixed time-slice for executing a given process. Process requests are handled by the task scheduler for creating a process. When a new process is generated, it is first put into the waiting state with a process control block (PCB) and a unique task ID (Fig. 144.7). The system uses a resource control block (RCB) (Fig. 144.6) to manage system resources. Each task in the waiting state must be checked to see if there are enough resources for its execution. If resources are available, it is transferred into the ready state, otherwise it has to be re-queued at the tail of the waiting queue until resources are available. Process Request

Creating (1)

Resource available

Ready (2)

Schedule

Time-out

Interrupt return Interrupt

Interrupt Services (9)

Interrupt Return

Running (3)

Completed

Wait for Event

Time available

Interrupted (5)

Delayed (6)

Event Available

Delete

Interrupt

Completed (4)

Delete

Delete

Killed (8)

Fig. 144.7 Process state transition diagram of RTOS+

11

Suspended (7)

The task scheduler continuously checks the ready queue for any ready tasks. If there are ready tasks, it executes the first task in the queue until it is completed (State 4) or is suspended. There are three conditions that may cause a running task to be suspended during execution: a) interrupted by a task or event with higher priority, b) time-out for a scheduled time-slice of CPU, and c) waiting for a specific event. The scheduler may remove the CPU from a running task if a higher priority interrupt request occurs. Such interruption will cause the running task to go into the interrupted queue and later return to the appropriate ready queue when the interrupt service is over. A task that has exhausted its assigned time-slice must go to the delayed queue. When a new CPU time-slice is available, it is rescheduled into the appropriate ready queue. A task that can no longer be executed due to waiting for an event goes into the suspended queue, and returns to the appropriate ready queue once the event has occurred. In any of these suspended cases, the task is put into a corresponding queue in States 5, 6, or 7 respectively. The task will be rescheduled into ready state when the cause of the suspension is no longer true. A task suspended may be cancelled (State 8) by the scheduler from the queues of States 5, 6, or 7 in case there is a lack of resources or under the request of users. 144.4.3 Formal Description of RTOS+ In the previous subsection, the conceptual model of RTOS+ has been established. To further refine the design of RTOS+, real-time process algebra (RTPA) is adopted as a formal specification means [Wang, 2002/2003]. RTPA is a mathematical notation capable of specifying and describing both architectures and behaviours of real-time systems. The dynamic behaviors of RTOS+ can be described by the interactions of parallel processes between TaskScheduling, TimeManagement, ResourceManagement, and SystemControlUpdate as shown in Fig. 144.8. RTOS+ runs the TaskManagment routine continuously by updating and dispatching various processes in different queues. If an interrupt occurs during run-time, the interrupt handling process (SysClock100msInst) saves the current executing environment, switches control to the interrupting process, and then automatically returns to the interrupted process following completion of a higher priority operation. SysClock100msInt handles low level interrupt events, such as system ResourceManagement at 100ms intervals.

12

RTOS.ProcessDeployment ≙ { // Basic level processes @SystemInitial ↳ ( SysInitial ↳

@ SysShutDown =T

R

TaskManagement

≥1

→⊠ ) || // High-interrupt level processes ⊙ @SysClock1msInt Ê ( SysClock ↳ TaskScheduling ↳ SystemControlBlockUpdate ↳ InterruptManagement ↳ TimeManagement ↳ HighPriorityEventScan ) Ì⊙ || // Low-interrupt level processes ⊙ @SysClock100msInt Ê( BaseEventScane ↳ ResourceManagement) Ì⊙

}

Fig.144.8 Real-time process deployment in RTOS+

Corresponding to the state transition diagram as shown in Fig. 144.7, the task scheduler of RTOS+ is specified by RTPA in Fig. 144.9. RTPA describes a finite state machine as an event-driven process dispatching system, where a specific event is used to trigger a predefined process. Process dispatch in RTPA models dynamic process relations behaving at run-time. The process dispatching mechanism of RTPA is used to formally describe the RTOS+ dynamic behaviors by a set of event-driven relationships between system events and functional processes of the operating system kernel. TaskScheduler ≙

{ ? ⓢNewProcRequestBL = T → CreatePCB (; → ProcStateN = 1 | ? ⓢPCB.ProcStateN ≥ 1 ? ProcStateN | 1 → Waiting () | 2 → Ready () | 3 → Running ()

| 4 → Completed ()

| 5 → Interrupted () | 6 → Delayed () | 7 → Suspended () | 8 → Killed () | 9 → InterruptServices () |?~→∅ }

Fig.144.9 Dynamic behaviors of the RTOS+ task scheduler

13

The core operations of RTOS+, such as task scheduling, time, event and resource management are rigorously described for better real-time performance and improved resource utilization. On the basis of the formal specification of RTOS+ by RTPA, architectural and behavioral consistency and correctness of RTOS+ can be improved. RTOS+ has been found useful in a wide range of applications in real-time and embedded system design.

144.5 Conclusions An operating system has been perceived as the agent between the hardware and computing resources of a computer or a computer network and the applications and users, which manages and controls the resources and computing capability, and provides users a logical interface for accessing the physical computer in executing computing applications. This chapter has described typical architectures and generic functions of operating systems. The basic concept and brief history of operating system technologies have been reviewed. The conceptual and typical commercial architectures of operating systems have been illustrated. The common functions of operating systems, such as process and thread management, memory management, file system management, I/O system management, and network/communication management, have been described. A real-time operating system, RTOS+, has been presented with a formal description by using real-time process algebra (RTPA).

Acknowledgement The author would like to thank L.F. Cabrera and C.F. Ngolah for their work and comments on this chapter.

References Anderson, T.E., E.D. Lazowska, and H.M. Levy (1989), The Performance Implications of Thread Management Alternatives for Shared-Memory Multiprocessors, IEEE Transactions on Computers, Dec., 38(12):1631-1644. Brinch-Hansen, P. (1971), Short-Term Scheduling in Multiprogramming Systems, Proceedings of the Third ACM Symposium on Operating Systems Principles, Oct., pp.103-105. Comer, D.E. (2000), Internetworking with TCP/IP, Vol. I: Principles, Protocols, and Architecture, 4th ed., PrenticeHall International, Inc. Comer, D.E. and Stevens, D. L. (1996), Internetworking with TCP/IP, Vol. III: Client-Server Programming and Application, Prentice-Hall International, Inc. Computer Systems Research Group – University of California at Berkeley (1986), BSD UNIX Reference Manuals, USENIX Association, CA. Day, J.D. and H. Zimmermann (1983), The OSI Reference Model, Proc. of the IEEE, Vol.71, Dec., pp. 1444-1340. Deitel, H. M. and Kogan, M. S. (1992), The Design of OS/2, Addison-Wesley, Reading, MA. Dijkstra, E.W. (1968), The Structure of the THE Multiprogramming System, Communications of the ACM, May, 11(5):341-346. Earhart, S.V. ed. (1986), AT&T UNIX Programmer’s Manual, Holt, Rinehart, and Winston, New York, NY. Labrosse, J.J. (1999), MicroC/OS-II, The Real-Time Kernel, 2nd ed., R&D Books, Gilroy, CA, December. Laplante, P.A. (1977), Real-Time Systems Design and Analysis, 2nd Edition, IEEE Press. Lewis, B. and D. Berg (1998), Multithreaded Programming with Pthreads, Sun Microsystems Press, Upper Saddle River, NJ. Liu, J. (2000), Real-time Systems, Prentice Hall, Upper Saddle River, NJ. Microsoft Corp. (1986), Microsoft MS-DOS User’s Reference and Microsoft MS-DOS Programmer’s Reference, Microsoft Press, Redmond, WA. Peterson, J. L. and Silberschantz, A. (1985), Operating System Concepts. Addison-Wesley, Reading, MA. Silberschatz, A., P. Galvin, and G. Gagne (2003), Applied Operating System Concepts, 1st ed., John Wiley & Sons, Inc., Danvers, MA.

14

Siever, E., A. Weber, S. Figgins, and A. Oram (2003), Linux in a Nutshell, 4th ed., O'Reilly & Associates. Sloane, A. (1993), Computer Communications: Principles and Business Applications, McGraw-Hill Book Co. Stallings, W. (2000), Local and Metropolitan Area Networks, 6th ed., Prentice Hall Inc. Tanenbaum, A.S. (1994), Distributed Operating Systems, Prentice Hall Inc. Tanenbaum, A.S. and A. Tanenbaum (2001), Modern Operating Systems, Prentice Hall Inc. Thomas, R., L.R. Rogers, and J.L. Yates (1986), Advanced Programmer’s Guide to Unix System V, Osborne McGraw-Hill, Berkeley, Ca. Wang, Y. (2002), The Real-Time Process Algebra (RTPA), Annals of Software Engineering: An International Journal, Kluwer Academic Publishers, 14: 235-274. Wang, Y. (2002), A New Approach to Real-Time Systems Specification, Proceedings of the 2002 IEEE Canadian Conference on Electrical and Computer Engineering (CCECE’02), Winnipeg, MB, Canada, May, Vol. 2, pp. 663-668. Wang, Y. (2003), Using Process Algebra to Describe Human and Software Behaviors, A Transdisciplinary Journal of Neuroscience and Neurophilosophy, 4(2), pp.199-213. Wang, Y. and C.F. Ngolah (2003), Formal Description of Real-Time Operating Systems using RTPA, Proceedings of the 2003 Canadian Conference on Electrical and Computer Engineering (CCECE’03), IEEE CS Press, Montreal, Canada, May, pp.35.3.1-4.

15

Figure Captions Figure 144.1 The role of an operating system in a general-purpose computer Figure 144.2 The generic architecture of operating systems Figure 144.3 The architecture of Unix Figure 144.4 The architecture of Windows XP Figure 144.5 The OSI reference model and TCP/IP Figure 144.6 The architecture of RTOS+ Figure 144.7 Process state transition diagram of RTOS+ Figure 144.8 Real-time process deployment in RTOS+ Figure 144.9 Dynamic behaviors of the RTOS+ task scheduler

16