Operating system

For a computer to be able to operate a computer programme (sometimes known as

application or software), the machine must be able to perform a certain number of preparatory
operations to ensure exchange between the processor, the memory and the physical resources
(peripherals).
The operating system (sometimes referred to by its abbreviation OS), is responsible for
creating the link between the material resources, the user and the applications (word processor,
video game, etc.). When a programme wants to access a material resource, it does not need to
send specific information to the peripheral device but it simply sends the information to the
operating system, which conveys it to the relevant peripheral via its driver. If there are no
drivers, each programme has to recognise and take into account the communication with each
type of peripheral!

The operating system thus allows the "dissociation" of programmes and hardware, mainly
to simplify resource management and offer the user a simplified Man-machine interface (MMI) to
overcome the complexity of the actual machine.

Serial processing
The earliest computer system has no OS at all, and is characterized as serial processing
because users have to reserve time slots in advance, and during the alloted period, they occupy
the computer exclusively. Thus the computer will be used in sequence by different users.
These early systems presented two major problems:

1. Users may finish their tasks earlier than you have expected, and unfortunately the rest time is
simply wasted. Or they may run into problems, cannot finish in the allotted time, and thus are
forced to stop, which causes much inconvenience and delays the development.

2. In such systems, programs are presented by cards. Each card has several locations on it,
where there may be a hole or not, respectively indicating 0 or 1. Programs are loaded into
memory via a card reader. With no OS available, to compile their programs, users have to
manually load the compiler program first with the user program as input. This involves mounting,
or dismounting tapes or setting up card decks. If an error occurred, the user has to repeat the
whole process from the very beginning. Thus much time is wasted.

Simple batch systems

To improve the utilization of computer systems, the concept of a batch operating system
was developed later on. The central idea is the use of a piece of software known as the monitor.
With it, users don’t have direct access to the computer systems any longer; instead, the operator
of the system collects the user programs and batches them together sequentially for use by the
monitor.
To process user programs, the monitor first has to be loaded into memory. Then it reads in
programs one at a time from the input devices. As each program is read in, it will be placed in
the user program area of main memory, and control is passed to this program. When the
execution of the program is completed, it returns control to the monitor, which moves on to
process the next program.
Multiprogrammed batch systems
Even with the automatic job processing by a monitor, the processor is still often idle. The
problem is actually what we have discussed before regarding programmed I/O. That is a
program may have to wait for I/O operation to
finish and thus leads to the processor’s idling. The solution is to run multiple programs
concurrently during a certain period so that whenever the current program has to wait for I/O
devices, control may be transferred to another program. If needed, a third program may be
loaded, or even more. This scheme is called multiprogramming or multitasking. With
multiprogramming, the utilization of processor is greatly improved, but it has its own problems.
To run multiple programs concurrently, the memory should be organized properly so that each
program has its own space and does not invade others’. What’s more, at some moment, there
may be more than programs ready to run. Thus some form of scheduling is needed to obtain
better performance.

Time-sharing system
With multiprogramming, the overall system is quite efficient. However a problem remains.
That is those jobs that come late in the batch job list won’t get chance to run until the jobs
before them have completed, thus their users have to wait a long time to obtain the results.
Some programs may even need interaction with users, which requires the processor to switch to
these programs frequently. To reach this new goal, a similar technique to multiprogramming can
be used, called time sharing. In such a system, multiple users simultaneously access the system
through terminals, with the operating system interleaving the execution of each user program in
a short burst of computation. For example, suppose a computer system may have at most 10
users at the same time, and the human reaction time is 200 ms. Then we may assign 200/10 =
20ms CPU time to the user programs one by one in a cyclic manner, thus each user will be
responded within the human reaction time so that the computer system seems to service the
user program itself.

The following table gives the difference between the batch multiprogramming and time
sharing:

System call

A system call is a request made by any program to the operating system for performing
tasks -- picked from a predefined set -- which the said program does not have required
permissions to execute in its own flow of execution. System calls provide the interface between a
process and the operating system. Most operations interacting with the system require
permissions not available to a user level process, e.g. I/O performed with a device present on the
system or any form of communication with other processes requires the use of system calls.

The fact that improper use of the system call can easily cause a system crash necessitates
some level of control. The design of the microprocessor architecture on practically all modern
systems (except some embedded systems) offers a series of privilege levels -- the (low)
privilege level in which normal applications execute limits the address space of the program so
that it cannot access or modify other running applications nor the operating system itself. It also
prevents the application from directly using devices (e.g. the frame buffer or network devices).
But obviously many normal applications need these abilities; thus they can call the operating
system. The operating system executes at the highest level of privilege and allows the
applications to request services via system calls, which are often implemented through
interrupts. If allowed, the system enters a higher privilege level, executes a specific set of
instructions which the interrupting program has no direct control over, then returns control to the
former flow of execution. This concept also serves as a way to implement security.
 With the development of separate operating modes with varying levels of privilege, a
mechanism was needed for transferring control safely from lesser privileged modes to higher
privileged modes. Less privileged code could not simply transfer control to more privileged code
at any point and with any processor state. To allow it to do so would allow it to break security.
For instance, the less privileged code could cause the higher privileged code to execute in the
wrong order, or provide it with a bad stack.

Interrupt Processing
An interrupt is a dynamic event that needs prompt attention by the CPU. Usually an
interrupt only needs a short period of CPU time to serve it. After that the original process can
resume its execution.

There are two types interrupting events: hardware interrupts that are those issued by
I/O device controllers when they need CPU to process I/O data, and software interrupts, also
called traps, that are raised when the current process executes a special trap instruction to
indicate that something wrong has happened or the process needs special service from the
operating system (like performing some I/O operation).

Only a limited number of types of interrupts are defined. For each type of I/O devices,
there is a special program called an interrupt handler to serve the interrupt requests from
these devices. For all software traps, there is also a special trap handler defined.

Each type of interrupt has an associated priority level. A running process would only be
interrupted by an interrupt source or trap of higher priority. When the CPU is executing an
interrupt handler, the interrupt handler may be further interrupted by an interrupt source of even
higher priority.

As we mentioned earlier, each type of interrupts will be processed by its own special
interrupt handler. These interrupt handlers are an important component of an operating system.
The starting address of each of these interrupt handlers are saved in a table called an Interrupt
Vector. The Interrupt Vector is usually stored at the lower end of the main memory, starting
from address 0. Suppose an I/O device has ID 3, then the starting address of its interrupt handler
is in memory address 3.

Upon entering the interrupt processing phase, the following events will happen:
a. Reset (put 0 in) the Interrupt Enabled Bit to disable further nested interrupting
b. The hardware will automatically push all the values of the program counter and
general purpose-registers into a system stack
c. Suppose the Address Lines of the system bus is now carrying k, where k is a small
integer, the kth memory word’s value (the starting address of the interrupt handler for the
current interrupt source) will be loaded into the CPU program counter, and the CPU starts
to run the interrupt handler.

The interrupt handler will do the following steps:

a. If necessary, save more state information for the interrupted process. For
example, maybe the carry bit of the ALU is needed by this handler thus needs to be saved.
b. Set (put 1 in) the Interrupt Enabled Bit to enable further nested interrupting
c. Do the necessary processing designed for this type of interrupt or trap. Typically,
some data will be transferred between a CPU register and one of the registers of an I/O
device controller. Since the interrupt is now enabled, it is possible that the execution of
this interrupt handler be further interrupted by sources of even higher priority.
d. Restore any information saved in step a.
e. Upon quitting the interrupt handler, pop the values of the program counter and
general-purpose registers of the interrupted process back into these registers.
f. Now the CPU can resume the execution of the interrupted process.
 Memory
Internal storage areas in the computer. The term memory identifies data storage that
comes in the form of chips, and the word storage is used for memory that exists on tapes or
disks. Moreover, the term memory is usually used as a shorthand for physical memory, which
refers to the actual chips capable of holding data. Some computers also use virtual memory,
which expands physical memory onto a hard disk.

Every computer comes with a certain amount of physical memory, usually referred to as
main memory or RAM. You can think of main memory as an array of boxes, each of which can
hold a single byte of information. A computer that has 1 megabyte of memory, therefore, can
hold about 1 million bytes (or characters) of information.

There are several different types of memory:

RAM (random-access memory): This is the same as main memory. When used by itself,
the term RAM refers to read and write memory; that is, you can both write data into RAM and
read data from RAM. This is in contrast to ROM, which permits you only to read data. Most RAM is
volatile, which means that it requires a steady flow of electricity to maintain its contents. As soon
as the power is turned off, whatever data was in RAM is lost.

ROM (read-only memory): Computers almost always contain a small amount of read-
only memory that holds instructions for starting up the computer. Unlike RAM, ROM cannot be
written to.

PROM (programmable read-only memory): A PROM is a memory chip on which you

can store a program. But once the PROM has been used, you cannot wipe it clean and use it to
store something else. Like ROMs, PROMs are non-volatile.

EPROM (erasable programmable read-only memory): An EPROM is a special type of

PROM that can be erased by exposing it to ultraviolet light.

EEPROM (electrically erasable programmable read-only memory): An EEPROM is a

special type of PROM that can be erased by exposing it to an electrical charge.

Cache Memory

Cache (pronounced cash) memory is extremely fast memory that is built into a computer’s
central processing unit (CPU), or located next to it on a separate chip. The CPU uses cache
memory to store instructions that are repeatedly required to run programs, improving overall
system speed. The advantage of cache memory is that the CPU does not have to use the
motherboard’s system bus for data transfer. Whenever data must be passed through the system
bus, the data transfer speed slows to the motherboard’s capability. The CPU can process data
much faster by avoiding the bottleneck created by the system bus.

As it happens, once most programs are open and running, they use very few resources.
When these resources are kept in cache, programs can operate more quickly and efficiently. All
else being equal, cache is so effective in system performance that a computer running a fast CPU
with little cache can have lower benchmarks than a system running a somewhat slower CPU with
more cache. Cache built into the CPU itself is referred to as Level 1 (L1) cache. Cache that
resides on a separate chip next to the CPU is called Level 2 (L2) cache. Some CPUs have both L1
and L2 cache built-in and designate the separate cache chip as Level 3 (L3) cache.

Cache that is built into the CPU is faster than separate cache, running at the speed of the
microprocessor itself. However, separate cache is still roughly twice as fast as Random Access
Memory (RAM). Cache is more expensive than RAM, but it is well worth getting a CPU and
motherboard with built-in cache in order to maximize system performance.
 Process
A process is an instance of a program running in a computer. It is close in meaning to
task , a term used in some operating systems. In Windows and some other operating systems, a
process is started when a program is initiated (either by a user entering a shell command or by
another program). Like a task, a process is a running program with which a particular set of data
is associated so that the process can be kept track of. An application that is being shared by
multiple users will generally have one process at some stage of execution for each user.

A process can initiate a subprocess, which is a called a child process (and the initiating
process is sometimes referred to as its parent ). A child process is a replica of the parent process
and shares some of its resources, but cannot exist if the parent is terminated.

Processes can exchange information or synchronize their operation through several

methods of interprocess communication.

Process Model
The process model is typically used in structured analysis and design methods. Also called
a data flow diagram (DFD), it shows the flow of information through a system. Each process
transforms inputs into outputs.

The model generally starts with a context diagram showing the system as a single process
connected to external entities outside of the system boundary. This process explodes to a lower
level DFD that divides the system into smaller parts and balances the flow of information
between parent and child diagrams. Many diagram levels may be needed to express a complex
system. Primitive processes, those that don't explode to a child diagram, are usually described in
a connected textual specification.

The Five state Model:

Events such as suspending and resuming are controlled by the MLS (Medium Level
Scheduler). A suspended process is dormant and this happens mostly when it is being swapped
out of memory by the memory management system. This decision is handled by the scheduler.

The process could be suspended while in RUNNING, READY or BLOCKED state. The result is
that two new state are produced READY SUSPENDED and BLOCKED SUSPENDED. Figure below
represents five state model.
 I/O COMPLRTION
ENTRY

READY BLOCKED

I/O WAIT
DISPATCH

RUNNING RESUME SUSPEND

TIMEOUT
SUSPEND

RESUME

TERMINATION

READY SUSPENDED SUSPEND

BLOCKED SUSPENDED

I/O COMPLETION

Five state
diagram
The five state diagram is derived from three stage diagram by adding the SUSPEND
condition. The SUSPEND condition can apply to any one of the states which are READY, RUNNING
and BLOCKED. A suspension on any state will stop the activity within that state.
If the READY and BLOCKED state are SUSPENDED then we obtain two more states called
SUSPENDED READY and SUSPENDED BLOCKED. If a RUNNING state is SUSPENDED then the
process is removed from the RUNNING state and placed in the SUSPENDED READY state.

It is also worth noting that if the I/O wait for BLOCKED SUSPENDED state returns the
‘awaited’ I/O request during the BLOCKED SUSPENDED state, the process is moved to the READY
SUSPENDED state.

Five states: New, Ready, Running, Blocked, Exit

New : A process has been created but has not yet been admitted to the pool of executable
processes.

Ready : Processes that are prepared to run if given an opportunity. That is, they are not waiting
on anything except the CPU availability.

Running: The process that is currently being executed. (Assume single processor for simplicity.)

Blocked : A process that cannot execute until a specified event such as an IO completion
occurs.

Exit: A process that has been released by OS either after normal termination or after abnormal
termination (error).

Classical Problems of Synchronization

1. Bounded-Buffer Problem
2. Readers and Writers Problem

READERS/WRITERS PROBLEM
In dealing with the design of synchronization and concurrency mechanisms, it is useful to
be able to relate the problem at hand to known problems and to be able to test any solution in
terms of its ability to solve these known problems. In the literature, several problems have
assumed importance and appear frequently, both because they are examples of common design
problems and because of their educational value. One such problem is the producer/consumer
problem, which has already been explored. In this section, we look at another classic problem:
the readers/writers problem.
The conditions that must be satisfied are as follows:
1. Any number of readers may simultaneously read the file.
2. Only one writer at a time may write to the file.
3. If a writer is writing to the file, no reader may read it.

Writers Have Priority

In the previous solution, readers have priority. Once a single reader has begun to access
the data area, it is possible for readers to retain control of the data area as long as there is at
least one reader in the act of reading. Therefore, writers are subject to starvation.
Figure shows a solution that guarantees that no new readers are allowed access to the
data area once at least one writer has declared a desire to write. For writers, the following
semaphores and variables are added to the ones already defined:
A semaphore rsem that inhibits all readers while there is at least one writer desiring
access to the data area
A variable writecount that controls the setting of rsem
A semaphore y that controls the updating of writecount

THE PRODUCER/CONSUMER PROBLEM

We now examine one of the most common problems faced in concurrent processing: the
producer/consumer problem. The general statement is this: there are one or more producers
generating some type of data (records, characters) and placing these in a buffer. There is a
single consumer that is taking items out of the buffer one at a time. The system is to be
constrained to prevent the overlap of buffer operations. That is, only one agent (producer or
consumer) may access the buffer at any one time. The problem is to make sure that the
producer won’t try to add data into the buffer if it’s full and that the consumer won’t try to
remove data from an empty buffer. We will look at a number of solutions to this problem to
illustrate both the power and the pitfalls of semaphores.
Let us add a new and realistic restriction to the producer/consumer problem: namely, that
the buffer is finite. The buffer is treated as a circular storage, and pointer values must be
expressed modulo the size of the buffer. The following relationships hold:

Deadlock
 Recall that one definition of an operating system is a resource allocator. There are many
resources that can be allocated to only one process at a time, and we have seen several
operating system features that allow this, such as mutexes, semaphores or file locks.

Sometimes a process has to reserve more than one resource. For example, a process which
copies files from one tape to another generally requires two tape drives. A process which deals
with databases may need to lock multiple records in a database.

In general, resources allocated to a process are not preemptable; this means that once a
resource has been allocated to a process, there is no simple mechanism by which the system
can take the resource back from the process unless the process voluntarily gives it up or the
system administrator kills the process. This can lead to a situation called deadlock. A set of
processes or threads is deadlocked when each process or thread is waiting for a resource to be
freed which is controlled by another process. Here is an example of a situation where deadlock
can occur.

Traffic gridlock is an everyday example of a deadlock

situation.

In order for deadlock to occur, four conditions must be true.

• Mutual exclusion - Each resource is either currently allocated to exactly one process or it
is available. (Two processes cannot simultaneously control the same resource or be in
their critical section).
• Hold and Wait - processes currently holding resources can request new resources
• No preemption - Once a process holds a resource, it cannot be taken away by another
process or the kernel.
• Circular wait - Each process is waiting to obtain a resource which is held by another
process.
• The deadlock situation in the above code can be modeled like this.

Deadlock detection and recovery

As we saw above, if there is only one instance of each resource, it is possible to detect deadlock
by constructing a resource allocation/request graph and checking for cycles. Graph theorists
have developed a number of algorithms to detect cycles in a graph. The book discusses one of
these. It uses only one data structure L a list of nodes.

A cycle detection algorithm

For each node N in the graph

 1. Initialize L to the empty list and designate all edges as unmarked
2. Add the current node to L and check to see if it appears twice. If it does, there is a cycle in
the graph.
3. From the given node, check to see if there are any unmarked outgoing edges. If yes, go to
the next step, if no, skip the next step
4. Pick an unmarked edge, mark it, then follow it to the new current node and go to step 3.
5. We have reached a dead end. Go back to the previous node and make that the current
node. If the current node is the starting Node and there are no unmarked edges, there are
no cycles in the graph. Otherwise, go to step 3.

Let's work through an example with five processes and five resources. Here is the resource
request/allocation graph.

The algorithm needs to search each node; let's start at node P1. We add P1 to L and follow
the only edge to R1, marking that edge. R1 is now the current node so we add that to L, checking
to confirm that it is not already in L. We then follow the unmarked edge to P2, marking the edge,
and making P2 the current node. We add P2 to L, checking to make sure that it is not already in
L, and follow the edge to R2. This makes R2 the current node, so we add it to L, checking to
make sure that it is not already there. We are now at a dead end so we back up, making P2 the
current node again. There are no more unmarked edges from P2 so we back up yet again,
making R1 the current node. There are no more unmarked edges from R1 so we back up yet
again, making P1 the current node. Since there are no more unmarked edges from P1 and since
this was our starting point, we are through with this node (and all of the nodes visited so far).

We move to the next unvisited node P3, and initialize L to empty. We first follow the unmarked
edge to R1, putting R1 on L. Continuing, we make P2 the current node and then R2. Since we are
at a dead end, we repeatedly back up until P3 becomes the current node again.

L now contains P3, R1, P2, and R2. P3 is the current node, and it has another unmarked edge to
R3. We make R3 the current node, add it to L, follow its edge to P4. We repeat this process,
visiting R4, then P5, then R5, then P3. When we visit P3 again we note that it is already on L, so
we have detected a cycle, meaning that there is a deadlock situation.

Once deadlock has been detected, it is not clear what the system should do to correct the
situation. There are three strategies.

Preemption - we can take an already allocated resource away from a process and give it to
another process. This can present problems. Suppose the resource is a printer and a print job is
half completed. It is often difficult to restart such a job without completely starting over.
Rollback - In situations where deadlock is a real possibility, the system can periodically make a
record of the state of each process and when deadlock occurs, roll everything back to the last
checkpoint, and restart, but allocating resources differently so that deadlock does not occur. This
means that all work done after the checkpoint is lost and will have to be redone.

Kill one or more processes - this is the simplest and crudest, but it works.

Deadlock avoidance

The above solution allowed deadlock to happen, then detected that deadlock had occurred
and tried to fix the problem after the fact. Another solution is to avoid deadlock by only granting
resources if granting them cannot result in a deadlock situation later. However, this works only if
the system knows what requests for resources a process will be making in the future, and this is
an unrealistic assumption. The text describes the bankers algorithm but then points out that it is
essentially impossible to implement because of this assumption.

Deadlock Prevention

The difference between deadlock avoidance and deadlock prevention is a little subtle.
Deadlock avoidance refers to a strategy where whenever a resource is requested, it is only
granted if it cannot result in deadlock. Deadlock prevention strategies involve changing the rules
so that processes will not make requests that could result in deadlock.

Here is a simple example of such a strategy. Suppose every possible resource is numbered (easy
enough in theory, but often hard in practice), and processes must make their requests in order;
that is, they cannot request a resource with a number lower than any of the resources that they
have been granted so far. Deadlock cannot occur in this situation.

As an example, consider the dining philosophers problem. Suppose each chopstick is numbered,
and philosophers always have to pick up the lower numbered chopstick before the higher
numbered chopstick. Philosopher five picks up chopstick 4, philosopher 4 picks up chopstick 3,
philosopher 3 picks up chopstick 2, philosopher 2 picks up chopstick 1. Philosopher 1 is hungry,
and without this assumption, would pick up chopstick 5, thus causing deadlock. However, if the
lower number rule is in effect, he/she has to pick up chopstick 1 first, and it is already in use, so
he/she is blocked. Philosopher 5 picks up chopstick 5, eats, and puts both down, allows
philosopher 4 to eat. Eventually everyone gets to eat.

An alternative strategy is to require all processes to request all of their resources at once, and
either all are granted or none are granted. Like the above strategy, this is conceptually easy but
often hard to implement in practice because it assumes that a process knows what resources it
will need in advance.

SCHEDULING ALGORITHMS

Short-Term Scheduling Criteria

The main objective of short-term scheduling is to allocate processor time in such a way as
to optimize one or more aspects of system behavior. Generally, a set of criteria is established
against which various scheduling policies may be evaluated. The commonly used criteria can be
categorized along two dimensions. First, we can make a distinction between user-oriented and
system-oriented criteria. User oriented criteria relate to the behavior of the system as perceived
by the individual user or process. An example is response time in an interactive system.
Response time is the elapsed time between the submission of a request until the response
begins to appear as output. This quantity is visible to the user and is naturally of interest to the
user. We would like a scheduling policy that provides “good” service to various users. In the case
of response time, a threshold may be defined, say 2 seconds. Then a goal of the scheduling
mechanism should be to maximize the number of users who experience an average response
time of 2 seconds or less
First-Come-First-Served
The simplest scheduling policy is first-come-first served (FCFS), also known as first-in-first-
out (FIFO) or a strict queuing scheme. As each process becomes ready, it joins the ready queue.
When the currently running process ceases to execute, the process that has been in the ready
queue the longest is selected for running. FCFS performs much better for long processes than
short ones. Consider the following example, based on one in [FINK88]:

Round Robin
A straightforward way to reduce the penalty that short jobs suffer
with FCFS is to use preemption based on a clock. The simplest such
policy is round robin. A clock interrupt is generated at periodic intervals.
When the interrupt occurs, the currently running process is placed in the
ready queue, and the next ready job is selected on a FCFS basis. This
technique is also known as time slicing, because each process is given a
slice of time before being preempted.
With round robin, the principal design issue is the length of the
time
quantum, or
slice, to be
used. If the
quantum is very short, then
short processes will
move through the system
relatively quickly. On the
other hand, there is processing
overhead involved in
handling the clock interrupt and performing the scheduling and dispatching function. Thus, very
short time quanta should be avoided. One useful guide is that the time quantum should be
slightly greater than the time required for a typical interaction or process function. If it is less,
then most processes will require at least two time quanta. Figure 9.6 illustrates the effect this
has on response time. Note that in the limiting case of a time quantum that is longer than the
longest-running process, round robin degenerates to FCFS.
Shortest Process Next
Another approach to reducing the bias in favor of long processes inherent in FCFS is the Shortest
Process Next (SPN) policy. This is a non-preemptive policy in which the process with the shortest
expected processing time is selected next. Thus a short process will jump to the head of the
queue past longer jobs.
Figure show the results for our example. Note that process E receives service much earlier
than under FCFS. Overall performance is also significantly improved in terms of response time.
However, the variability of response times is increased, especially for longer processes, and thus
predictability is reduced.

Shortest Remaining Time

The shortest remaining time (SRT) policy is a preemptive version of SPN. In this case, the
scheduler always chooses the process that has the shortest expected remaining processing time.
When a new process joins the ready queue, it may in fact have a shorter remaining time than the
currently running process. Accordingly, the scheduler may preempt the current process when a
new process becomes ready. As with SPN, the scheduler must have an estimate of processing
time to perform the selection function, and there is a risk of starvation of longer processes.
SRT does not have the bias in favor of long processes found in FCFS. Unlike round robin,
no additional interrupts are generated, reducing overhead. On the other hand, elapsed service
times must be recorded, contributing to overhead. SRT should also give superior turnaround time
performance to SPN, because a short job is given immediate preference to a running longer job.

THE CRITICAL-SECTION PROBLEM

n processes all competing to use some shared data
Each process has a code segment, called critical section, in which the shared data is
accessed.
Problem – ensure that when one process is executing in its critical section, no other
process is allowed to execute in its critical section.
Structure of process Pi
repeat
entry section
critical section
exit section
remainder section
until false;
Solution to Critical-Section Problem
1. Mutual Exclusion. If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections.
 2. Progress. If no process is executing in its critical section and there exist some processes
that wish to enter their critical section, then the selection of the processes that will enter
the critical section next cannot be postponed indefinitely.
3. Bounded Waiting. A bound must exist on the number of times that other processes are
allowed to enter their critical sections after a process has made a request to enter its
critical section and before that request is granted.

Assume that each process executes at a nonzero speed.

No assumption concerning relative speed of the n processes.

PAGING

When a program is selected for execution, the system brings it into virtual storage, divides
it into pages of four kilobytes, transfers the pages into central storage for execution. To the
programmer, the entire program appears to occupy contiguous space in storage at all times.
Actually, not all pages of a program are necessarily in central storage, and the pages that are in
central storage do not necessarily occupy contiguous space.

The pieces of a program executing in virtual storage must be moved between real and
auxiliary storage. To allow this, z/OS® manages storage in units, or blocks, of four kilobytes. The
following blocks are defined:

• A block of central storage is a frame.

• A block of virtual storage is a page.
• A block of auxiliary storage is a slot.

A page, a frame, and a slot are all the same size: Four kilobytes. An active virtual storage
page resides in a central storage frame. A virtual storage page that becomes inactive resides in
an auxiliary storage slot (in a paging data set). Figure 1 shows the relationship of pages, frames,
and slots.

In Figure , z/OS is performing paging for a program running in virtual storage. The lettered
boxes represent parts of the program. In this simplified view, program parts A, E, F, and H are
active and running in central storage frames, while parts B, C, D, and G are inactive and have
been moved to auxiliary storage slots. All of the program parts, however, reside in virtual storage
and have virtual storage addresses.

z/OS uses a series of tables to determine whether a page is in real or auxiliary

storage, and where. To find a page of a program, z/OS checks the table for the virtual
address of the page, rather than searching through all of physical storage for it. z/OS
then transfers the page into central storage or out to auxiliary storage as needed. This
movement of pages between auxiliary storage slots and central storage frames is called
paging. Paging is key to understanding the use of virtual storage in z/OS.

z/OS paging is transparent to the user. During job execution, only those pieces of
the application that are required are brought in, or paged in, to central storage. The
pages remain in central storage until no longer needed, or until another page is required
by the same application or a higher-priority application and no empty central storage is
available. To select pages for paging out to auxiliary storage, z/OS follows a "Least Used"
algorithm. That is, z/OS assumes that a page that has not been used for some time will
probably not be used in the near future.

DEMAND PAGING

In computer operating systems, demand paging is an application of virtual memory. In a system

that uses demand paging, the operating system copies a disk page into physical memory only if
an attempt is made to access it (i.e., if a page fault occurs). It follows that a process begins
execution with none of its pages in physical memory, and many page faults will occur until most
of a process's working set of pages is located in physical memory. This is an example of lazy
loading techniques.

Demand paging follows that pages should only be brought into memory if the executing process demands them.
This is often referred to as lazy evaluation as only those pages demanded by the process are swapped from
secondary storage to main memory. Contrast this to pure swapping, where all memory for a process is swapped
from secondary storage to main memory during the process startup.

When a process is to be swapped into main memory for processing, the pager guesses which pages will be used
prior to the process being swapped out again. The pager will only load these pages into memory. This process
avoids loading pages that are unlikely to be used and focuses on pages needed druing the current process
exection period. Therefore, we not only avoid unnecessary page load during swpping put we also try to preempt
which pages we will need and avoid loading pages during execution.

Commonly, to achieve this process a page table implementation is used. Our page table maps logical memory to
physical memory. The page table uses a bitwise operator to mark if a page is valid or invalid. A valid page is
one that currently resides in main memory. An invalid page table is one that currently resides in secondary
memory. When a process tries to access a page, the following steps are generally followed:

• Attempt to access page.

• If page is valid (in memory) then continue processing instruction as normal.
• If page is invalid then a page-fault trap occurs.
• Check if the memory reference is a valid reference to a location on secondary memory. If
not, we terminate the process (illegal memory access). Otherwise, we have to page in the
required page.
• Schedule disk operation to read the desired page into main memory.
• Restart the instruction that was interrupted by the operating system trap.

Advantages

Demand paging, as opposed to loading all pages immediately:

• Only loads pages that are demanded by the executing process.

• When a process is swapped out (context switch) of memory, only those pages loaded in
main memory need to be swapped out from main memory to secondary storage.
• As there is more space in main memory, more processes can be loaded reducing context
switching time which utilizes large amounts of resources.
• Less loading latency occurs at program startup, as less information is accessed from
secondary storage and less information is brought into main memory.
• Does not need extra hardware support than what paging needs, since protection fault can
be used to get page fault.

Disadvantages

• Individual programs face extra latency when they access a page for the first time. So
demand paging may have lower performance than anticipatory paging algorithms such as
 prepaging, a method of remembering which pages a process used when it last executed
and preloading a few of them, is used to improve performance.
• Programs running on low-cost, low-power embedded systems may not have a memory
management unit that supports page replacement.
• Memory management with page replacement algorithms becomes slightly more complex.
• Possible security risks, including vulnerability to timing attacks; see Percival 2005 Cache
Missing for Fun and Profit

MEMORY FRAGMENTATION

Memory fragmentation eventually occurs on all NetWare 4 servers. Depending on the way
you manage a server and the NetWare Loadable Modules (NLMs) you run, memory
fragmentation can occur daily or occasionally, over a period of years.

The most common cause of memory fragmentation is loading and unloading a scheduled
NLM, such as a backup NLM. However, other automated NLMs can also cause memory
fragmentation. For example, Novell's FTP server can cause memory fragmentation because the
FTP server automatically loads when a request is received and then unloads when the request
times out.

Memory fragmentation can also be caused by NLMs that are unloaded and then reloaded
as part of another process. For example, a backup NLM could schedule the unloading of a
database NLM during the backup process. The backup NLM would then reload the database NLM
when this process was completed.

Since a database NLM is designed to be loaded and left running, this NLM makes
permanent memory pool allocations, which are not returned to system memory when the NLM is
unloaded. When the database NLM is reloaded, it may not reuse its permanent memory pool
allocation and may, therefore, leave gaps in memory. As a result, memory fragmentation may
occur.

Although memory fragmentation can cause several errors, it most often results in Short
Term Memory Alloc messages at the server console. These messages indicate that small memory
resources are not available to the requesting process.

SOLUTIONS FOR MEMORY FRAGMENTATION

To resolve memory fragmentation, you should first ensure that the following command is
included in the STARTUP.NCF file before you load disk drivers or name space drivers:

• SET RESERVED BUFFERS BELOW 16 MEG = 300

By setting this parameter to 300, you allocate the largest memory pool possible in low
memory to be used for short-term memory allocations. As a result, NetWare 4 does not need to
allocate high memory to NLMs that make short-term memory allocations.

If changing this parameter does not resolve memory fragmentation, you must down the
server and restart it. If the server frequently experiences severe memory fragmentation, you
should identify which NLMs are being loaded and unloaded and determine how you can leave
these NLMs loaded all the time.

MEMORY SEGMENTATION

Memory segmentation occurs when system memory is presented to NetWare 4 as two or more
noncontiguous memory blocks. Although several factors can cause this condition, the result is
always the same: The NetWare Cache Memory Allocator cannot use all of the installed RAM.
Depending on the cause, NetWare 4 may or may not see all of the installed RAM.
If the NetWare Cache Memory Allocator cannot use all of the installed RAM, the server may
display error messages. Most frequently, the server reports that the NetWare Cache Memory
Allocator is out of available memory.

SOLUTIONS FOR MEMORY SEGMENTATION

The solutions used to resolve memory segmentation on NetWare 3 servers do not work on
NetWare 4 servers. NetWare 3 is based on a multipool memory model and doesn't allocate
memory for the NetWare Cache Memory Allocator until the first volume is mounted. As a result,
you can prevent disk drivers from loading in the STARTUP.NCF file, and you can use the
REGISTER MEMORY command before loading disk drivers and mounting volumes in the
AUTOEXEC.NCF file. NetWare 3 can then see all of the available memory before allocating
memory for the NetWare Cache Memory Allocator.

Unlike NetWare 3, NetWare 4, is based on a single-pool, flat-memory model. When

NetWare 4 is initialized, it immediately allocates memory for the NetWare Cache Memory
Allocator. As a result, NetWare 4 can allocate only the memory that is physically available at the
time. Once NetWare 4 allocates memory for the NetWare Cache Memory Allocator, NetWare 4
cannot dynamically reallocate this memory.

If you use the REGISTER MEMORY command to resolve memory segmentation, NetWare 4
cannot use the additional memory it sees for internal processes. NetWare 4 can use this
additional memory only for file cache buffers.

To resolve memory segmentation, you should first ensure that you have not imposed false
memory limitations on the server. Loading a DOS memory manager (HIMEM.SYS or EMM386.EXE,
for example) in the CONFIG.SYS file is one of the most common causes of memory segmentation.
You should also ensure that you are not loading a CONFIG.SYS file on the server's boot disk or
boot partition.

CONCLUSION

Memory fragmentation occurs with all operating systems, not just NetWare 4. If memory
fragmentation begins to affect system performance or data integrity, you must reboot the
server.

Memory segmentation, on the other hand, is caused by the physical limitations of the computer.
(Such physical limitations also affect all operating systems, not just NetWare 4.) Either the
computer is limited through its inherent design or through the use of devices that prevent
NetWare 4 from directly addressing all of the available memory. The best solution is to use a
computer that does not have these physical limitations.

PAGE REPLACEMENT ALGORITHMS

Regardless of the resident set management strategy (discussed in the next subsection), there
are certain basic algorithms that are used for the selection of a page to replace. Replacement
algorithms that have been discussed in the literature include
• Optimal
• Least recently used (LRU)
• First-in-first-out (FIFO)
• Clock

The optimal policy selects for replacement that page for which the time to the next
reference is the longest. It can be shown that this policy results in the fewest number of page
faults [BELA66]. Clearly, this policy is impossible to implement,
because it would require the operating system to have perfect knowledge of future events.
However, it does serve as a standard against which to judge real world algorithms.
Figure gives an example of the optimal policy. The example assumes a fixed frame
allocation (fixed resident set size) for this process of three frames. The execution of the process
requires reference to five distinct pages. The page address stream formed by executing the
program is
232152453252
which means that the first page referenced is 2, the second page referenced is 3, and so
on. The optimal policy produces three page faults after the frame allocation has been filled.

The least recently used (LRU) policy replaces the page in memory that has not been
referenced for the longest time. By the principle of locality, this should be the page least likely to
be referenced in the near future. And, in fact, the LRU policy does nearly as well as the optimal
policy. The problem with this approach is the difficulty in implementation. One approach would
be to tag each page with the time of its last reference; this would have to be done at each
memory reference, both instruction and data. Even if the hardware would support such a
scheme, the overhead would be tremendous. Alternatively, one could maintain a stack of page
references, again an expensive prospect.

The first-in-
first-out (FIFO) policy treats the page frames allocated
to a process as a circular buffer, and pages are removed in
round-robin style. All that is required is a pointer that
circles through the page frames of the process. This is
therefore one of the simplest page replacement policies to
implement. The logic behind this choice, other than its
simplicity, is that one is replacing the page that has been
in memory the longest: A page fetched into memory a long
time ago may have now fallen out of use. This reasoning
will often be wrong, because there will often be regions of
program or data that are heavily used throughout the life
of a program. Those pages will be repeatedly paged in and
out by the FIFO algorithm. Continuing our example in
Figure 8.15, the FIFO policy results in six page faults. Note
that LRU recognizes that pages 2 and 5 are referenced
more frequently than other pages, whereas FIFO does not.

Many of these algorithms are variants of a scheme

referred to as the clock policy. The simplest form of clock
policy requires the association of an additional bit with
each frame, referred to as the use bit. When a page is first
loaded into a frame in memory, the use bit for that frame
is set to 1.Whenever the page is subsequently referenced
(after the reference that generated the page fault), its use
bit is set to 1. For the page replacement algorithm, the set
of frames that are candidates for replacement (this process: local scope; all of main memory:
global scope5) is considered to be a circular buffer, with which a pointer is associated. When a
page is replaced, the pointer is set to indicate the next frame in the buffer after the one just
updated. When it comes time to replace a page, the operating system scans the buffer to find a
frame with a use bit set to zero. Each time it encounters a frame with a use bit of 1, it resets that
bit to zero and continues on. If any of the frames in the buffer have a use bit of zero at the
beginning of this process, the first such frame encountered is chosen for replacement. If all of
the frames have a use bit of 1, then the pointer will make one complete cycle through the buffer,
setting all the use bits to zero, and stop at its original position, replacing the page in that frame.
We can see that this policy is similar to FIFO, except that, in the clock policy, any frame with a
use bit of 1 is passed over by the algorithm. The policy is referred to as a clock policy because
we can visualize the page frames as laid out in a circle. A number of operating systems have
employed some variation of this simple clock policy (for example, Mastics [CORB68]).
 INDEX
• Operating system and its Types
Serial processing
Simple batch systems
Multiprogrammed batch systems
Time-sharing system

• System call
• Interrupt Processing
• Memory
• Cache Memory
• Process and Process Model
• Classical Problems of Synchronization
• Deadlock
Deadlock detection and recovery

• Scheduling Algorithms
• THE CRITICAL-SECTION PROBLEM
• PAGING
MEMORY FRAGMENTATION
• MEMORY SEGMENTATION
• PAGE REPLACEMENT ALGORITHMS