Input /Output (I/O) Management in o/s

⏪Previous Next⏩

So far we have studied how resources like processor and main memory are managed.
We shall now examine the I/O management. Humans interact with machines by providing information through IO devices.
Also, much of whatever a computer system provides as on-line services is essentially made available through specialized devices such as screen displays, printers, keyboards, mouse, etc. Clearly, management of all these devices can affect the throughput of a system.
For this reason, input output management also becomes one of the primary responsibilities of an operating system.
In this chapter we shall examine the role of operating systems in managing IO devices.
In particular, we shall examine how the end use of the devices determines the way they are regulated for communication with either humans or with systems.

Issues in I/O Management

Let us first examine the context of input output in a computer system. We shall look at issues initially from the point of view of communication with a device.
Later, we shall also examine issues from the point of view of managing events.
When we analyze device communication, we notice that communication is required at the

following three levels:

􀂾 The need for a human to input information and receive output from a computer.
􀂾 The need for a device to input information and receive output from a computer.
􀂾 The need for computers to communicate (receive/send information) over
networks.

The first kind of IO devices operate at rates good for humans to interact.
These may be character-oriented devices like a keyboard or an event-generating device like a mouse.
Usually, human input using a key board will be a few key depressions at a time.
This means that the communication is rarely more than a few bytes.
Also, the mouse events can be encoded by a small amount of information (just a few bytes).
Even though a human input is very small, it is stipulated that it is very important, and therefore requires an immediate response from the system.
A communication which attempts to draw attention often requires the use of an interrupt mechanism or a programmed data mode of operation. Interrupt as well as programmed data mode of IO shall be dealt with in detail later in this chapter.

Managing Events

Our next observation is that a computer system may sometimes be embedded to interact with a real-life activity or process.
It is quite possible that in some operational context a process may have to synchronize with some other process.
In such a case this process may actually have to wait to achieve a rendezvous with another process.
In fact, whichever of the two synchronizing processes arrives first at the point of rendezvous would have to wait.
When the other process also reaches the point of synchronization, the first process may proceed after recognizing the synchronizing event.
Note that events may be communicated using signals which we shall learn about later.
In some other cases a process may have to respond to an asynchronous event that may occur at any time.
Usually, an asynchronous input is attended to in the next instruction cycle as we saw In fact, the OS checks for any event which may have occurred in the intervening period.

Programmed Data Mode

In this mode of communication, execution of an IO instruction ensures that a program shall not advance till it is completed.
To that extent one is assured that IO happens before anything else happens.
in this mode an IO instruction is issued to an IO device and the program executes in “busy-waiting” (idling) mode till the IO is completed.
During the busy-wait period the processor is continually interrogating to check if the device has completed IO.
Invariably the data transfer is accomplished through an identified register and a flag in a processor.

Polling :

In this mode of data transfer the system interrogates each device in turn to determine if it is ready to communicate.
If it is ready, communication is initiated and subsequently the process continues again to interrogate in the same sequence.
This is just like a round-robin strategy. Each IO device gets an opportunity to establish Communication in turn.
No device has a particular advantage (like say a priority) over other devices. Polling is quite commonly used by systems to interrogate ports on a network.
Polling may also be scheduled to interrogate at some pre-assigned time intervals.
It should be remarked here that most daemon software operate in polling mode.
EssentiallyIn hardware, this may typically translate to the following protocol:

1.Assign a distinct address to each device connected to a bus.

2. The bus controller scans through the addresses in sequence to find which device
wishes to establish a communication.
3. Allow the device that is ready to communicate to leave its data on the register.
4. The IO is accomplished. In case of an input the processor picks up the data. In
case of an output the device picks up the data.
5. Move to interrogate the next device address in sequence to check if it is ready to communicate.