Polling, or interrogation, refers to actively sampling the status of an external device by a client program as a synchronous activity. Polling is most often used in terms of input/output (I/O), and is also referred to as polled I/O or software-driven I/O. A good example of hardware implementation is a watchdog timer.

Description

Polling is the process where the computer or controlling device waits for an external device to check for its readiness or state, often with low-level hardware. For example, when a printer is connected via a parallel port, the computer waits until the printer has received the next character. These processes can be as minute as only reading one bit. This is sometimes used synonymously with 'busy-wait' polling. In this situation, when an I/O operation is required, the computer does nothing other than check the status of the I/O device until it is ready, at which point the device is accessed. In other words, the computer waits until the device is ready. Polling also refers to the situation where a device is repeatedly checked for readiness, and if it is not, the computer returns to a different task. Although not as wasteful of CPU cycles as busy waiting, this is generally not as efficient as the alternative to polling, interrupt-driven I/O.

In a simple single-purpose system, even busy-wait is perfectly appropriate if no action is possible until the I/O access, but more often than not this was traditionally a consequence of simple hardware or non-multitasking operating systems.

Polling is often intimately involved with very low-level hardware. For example, polling a parallel printer port to check whether it is ready for another character involves examining as little as one bit of a byte. That bit represents, at the time of reading, whether a single wire in the printer cable is at low or high voltage. The I/O instruction that reads this byte directly transfers the voltage state of eight real world wires to the eight circuits (flip flops) that make up one byte of a CPU register.

Polling has the disadvantage that if there are too many devices to check, the time required to poll them can exceed the time available to service the I/O device.

Algorithm

Polling can be described in the following steps:

Host actions:

  1. The host repeatedly reads the busy bit of the controller until it becomes clear (with a value of 0).
  2. When clear, the host writes the command into the command register. If the host is sending output, it sets the write bit and writes a byte into the data-out register. If the host is receiving input, it reads the controller-written data from the data-in register, and sets the read bit to 0 as the next command.
  3. The host sets the command-ready bit to 1.

Controller actions:

  1. When the controller notices that the command-ready bit is set, it sets the busy bit to 1.
  2. The controller reads the command register. If the write bit inside is set, it reads from the data-out register and performs the necessary I/O operations on the device. If the read bit is set, data from the device is loaded into the data-in register for the host to read.
  3. Once the operations are over, the controller clears the command-ready bit, clears the error bit to show the operation was successful, and clears the busy bit.

Types

A polling cycle is the time in which each element is monitored once. The optimal polling cycle will vary according to several factors, including the desired speed of response and the overhead (e.g., processor time and bandwidth) of the polling.

In roll call polling, the polling device or process queries each element on a list in a fixed sequence. Because it waits for a response from each element, a timing mechanism is necessary to prevent lock-ups caused by non-responding elements. Roll call polling can be inefficient if the overhead for the polling messages is high, there are numerous elements to be polled in each polling cycle and only a few elements are active.

In hub polling, also referred to as token polling, each element polls the next element in some fixed sequence. This continues until the first element is reached, at which time the polling cycle starts all over again.

Polling can be employed in various computing contexts in order to control the execution or transmission sequence of the elements involved. For example, in multitasking operating systems, polling can be used to allocate processor time and other resources to the various competing processes.

In networks, polling is used to determine which nodes want to access the network. It is also used by routing protocols to retrieve routing information, as is the case with EGP (exterior gateway protocol).

An alternative to polling is the use of interrupts, which are signals generated by devices or processes to indicate that they need attention, want to communicate, etc. Although polling can be very simple, in many situations (e.g., multitasking operating systems) it is more efficient to use interrupts because it can reduce processor usage and/or bandwidth consumption.

Poll message

A poll message is a control-acknowledgment message.

In a multidrop line arrangement (a central computer and different terminals in which the terminals share a single communication line to and from the computer), the system uses a master/slave polling arrangement whereby the central computer sends message (called polling message) to a specific terminal on the outgoing line. All terminals listen to the outgoing line, but only the terminal that is polled replies by sending any information that it has ready for transmission on the incoming line.[1]

In star networks, which, in its simplest form, consists of one central switch, hub, or computer that acts as a conduit to transmit messages, polling is not required to avoid chaos on the lines, but it is often used to allow the master to acquire input in an orderly fashion. These poll messages differ from those of the multidrop lines case because there are no site addresses needed, and each terminal only receives those polls that are directed to it.[1]

See also

References

  1. 1 2 "Multi-Drop Polling". RAD Data Communications/Pulse Supply. 2007. Archived from the original on 2014-02-17. Retrieved 2014-07-13.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.