Krantiguru Shyamji Krishna Verma Kachchh University 2011 B.C.A Computer Application Practice for visual basic - Question Paper

MEMORY MANAGEMENT

Operating systems are among the most complex pieces of software ever developed.

This reflects the challenge of trying to meet the difficult and in some cases

competing objectives of convenience, efficiency, and ability to evolve.

proposes that there have been four major theoretical advances in the development

of operating systems:

Processes

Memory management

Information protection and security

Scheduling and resource management

Each advance is characterized by principles, or abstractions, developed to

meet difficult practical problems. Taken together, these five areas span many of

the key design and implementation issues of modern operating systems. The brief

review of these five areas in this section serves as an overview of much of the rest

of the text.

The Process

Central to the design of operating systems is the concept of process. This term was

first used by the designers of Multics in the 1960s [DALE68]. It is a somewhat

more general term than job. Many definitions have been given for the term process ,

including

A program in execution

An instance of a program running on a computer

The entity that can be assigned to and executed on a processor

A unit of activity characterized by a single sequential thread of execution, a

current state, and an associated set of system resources

This concept should become clearer as we proceed.

Three major lines of computer system development created problems in timing

and synchronization that contributed to the development of the concept of the

process: multiprogramming batch operation, time sharing, and real-time transaction

systems. As we have seen, multiprogramming was designed to keep the processor

and I/O devices, including storage devices, simultaneously busy to achieve maximum

efficiency. The key mechanism is this: In response to signals indicating the

completion of I/O transactions, the processor is switched among the various programs

residing in main memory.

MAJOR ACHIEVEMENTS

A second line of development was general-purpose time sharing. Here, the

key design objective is to be responsive to the needs of the individual user and yet,

for cost reasons, be able to support many users simultaneously. These goals are

compatible because of the relatively slow reaction time of the user. For example,

if a typical user needs an average of 2 seconds of processing time per minute, then

close to 30 such users should be able to share the same system without noticeable

interference. Of course, OS overhead must be factored into such calculations.

A third important line of development has been real-time transaction processing

systems. In this case, a number of users are entering queries or updates against a

database. An example is an airline reservation system. The key difference between

the transaction processing system and the time-sharing system is that the former

is limited to one or a few applications, whereas users of a time-sharing system can

engage in program development, job execution, and the use of various applications.

In both cases, system response time is paramount.

The principal tool available to system programmers in developing the early

multiprogramming and multiuser interactive systems was the interrupt. The activity

of any job could be suspended by the occurrence of a defined event, such as an I/O

completion. The processor would save some sort of context (e.g., program counter

and other registers) and branch to an interrupt-handling routine, which would

determine the nature of the interrupt, process the interrupt, and then resume user

processing with the interrupted job or some other job.

The design of the system software to coordinate these various activities turned

out to be remarkably difficult. With many jobs in progress at any one time, each of

which involved numerous steps to be performed in sequence, it became impossible

to analyze all of the possible combinations of sequences of events. In the absence of

some systematic means of coordination and cooperation among activities, programmers

resorted to ad hoc methods based on their understanding of the environment

that the OS had to control. These efforts were vulnerable to subtle programming

errors whose effects could be observed only when certain relatively rare sequences

of actions occurred. These errors were difficult to diagnose because they needed to

be distinguished from application software errors and hardware errors. Even when

the error was detected, it was difficult to determine the cause, because the precise

conditions under which the errors appeared were very hard to reproduce. In general

terms, there are four main causes of such errors

Improper synchronization: It is often the case that a routine must be suspended

awaiting an event elsewhere in the system. For example, a program

that initiates an I/O read must wait until the data are available in a buffer

before proceeding. In such cases, a signal from some other routine is required.

Improper design of the signaling mechanism can result in signals being lost or

duplicate signals being received.

Failed mutual exclusion: It is often the case that more than one user or program

will attempt to make use of a shared resource at the same time. For

example, two users may attempt to edit the same file at the same time. If

these accesses are not controlled, an error can occur. There must be some

sort of mutual exclusion mechanism that permits only one routine at a time

to perform an update against the file. The implementation of such mutual

exclusion is difficult to verify as being correct under all possible sequences

of events.

Nondeterminate program operation: The results of a particular program

normally should depend only on the input to that program and not on

the activities of other programs in a shared system. But when programs share

memory, and their execution is interleaved by the processor, they may interfere

with each other by overwriting common memory areas in unpredictable

ways. Thus, the order in which various programs are scheduled may affect the

outcome of any particular program.

Deadlocks: It is possible for two or more programs to be hung up waiting for

each other. For example, two programs may each require two I/O devices to

perform some operation (e.g., disk to tape copy). One of the programs has seized control of one of the devices and the other program has control of

the other device. Each is waiting for the other program to release the desired resource. Such a deadlock may depend on the chance timing of resource allocation and release.

What is needed to tackle these problems is a systematic way to monitor and control the various programs executing on the processor. The concept of the

process provides the foundation. We can think of a process as consisting of three

components:

An executable program

The associated data needed by the program (variables, work space, buffers, etc.)

The execution context of the program

This last element is essential. The execution context , or process state , is the

internal data by which the OS is able to supervise and control the process. This

internal information is separated from the process, because the OS has information

not permitted to the process. The context includes all of the information that the OS

needs to manage the process and that the processor needs to execute the process

properly. The context includes the contents of the various processor registers, such

as the program counter and data registers. It also includes information of use to the

OS, such as the priority of the process and whether the process is waiting for the

completion of a particular I/O event.

Figure 2.8 indicates a way in which processes may be managed. Two processes,

A and B, exist in portions of main memory. That is, a block of memory is

allocated to each process that contains the program, data, and context information.

Each process is recorded in a process list built and maintained by the OS. The

process list contains one entry for each process, which includes a pointer to the

location of the block of memory that contains the process. The entry may also

include part or all of the execution context of the process. The remainder of the

execution context is stored elsewhere, perhaps with the process itself or frequently in a separate region of memory. The process index register contains the index into the process list of the process currently controlling

the processor. The program counter points to the next instruction in that process

to be executed. The base and limit registers define the region in memory occupied

by the process: The base register is the starting address of the region of memory

and the limit is the size of the region (in bytes or words). The program counter and

all data references are interpreted relative to the base register and must not exceed

the value in the limit register. This prevents interprocess interference. the process index register indicates that process B is executing.Process A was previously executing but has been temporarily interrupted. The contents of all the registers at the moment of As interruption were recorded in its

execution context. Later, the OS can perform a process switch and resume execution of process A. The process switch consists of storing the context of B and restoring the context of A. When the program counter is loaded with a value pointing into As

program area, process A will automatically resume execution. Thus, the process is realized as a data structure. A process can either be executing or awaiting execution. The entire state of the process at any instant is contained in its context. This structure allows the development of powerful techniques for ensuring coordination and cooperation among processes. New features can be designed and incorporated into the OS (e.g., priority) by expanding the context to

Context

Data

Program

(code)

Context

Data

i

Process index

PC

Base

limit

Other

registers

i

bh

j

b

h

Process

B

Process

A

Main

memory

Processor

registers

Process

list

Program

(code)

include any new information needed to support the feature. Throughout this book,we will see a number of examples where this process structure is employed to solve the problems raised by multiprogramming and resource sharing.

A final point, which we introduce briefly here, is the concept of thread . In

essence, a single process, which is assigned certain resources, can be broken up into

multiple, concurrent threads that execute cooperatively to perform the work of the

process. This introduces a new level of parallel activity to be managed by the hardware

and software.

Memory Management

The needs of users can be met best by a computing environment that supports

modular programming and the flexible use of data. System managers need efficient

and orderly control of storage allocation. The OS, to satisfy these requirements, has

five principal storage management responsibilities:

Process isolation: The OS must prevent independent processes from interfering with each others memory, both data and instructions.

Automatic allocation and management: Programs should be dynamically allocated across the memory hierarchy as required. Allocation should be transparent to the programmer. Thus, the programmer is relieved of concerns relating to memory limitations, and the OS can achieve efficiency by assigning

memory to jobs only as needed.

Support of modular programming: Programmers should be able to define program modules, and to create, destroy, and alter the size of modules dynamically.

Protection and access control: Sharing of memory, at any level of the memory hierarchy, creates the potential for one program to address the memory space

of another. This is desirable when sharing is needed by particular applications.

At other times, it threatens the integrity of programs and even of the OS itself.

The OS must allow portions of memory to be accessible in various ways by

various users.

Long-term storage: Many application programs require means for storing

information for extended periods of time, after the computer has been

powered down.