Java Reference
In-Depth Information
only to be destroyed during output. The simple solution to this problem is to keep
one buffer for input, and a second for output.
Most disk drive controllers operate independently from the CPU once an I/O
request is received. This is useful because the CPU can typically execute millions
of instructions during the time required for a single I/O operation. A technique that
takes maximum advantage of this micro-parallelism is double buffering. Imagine
that a file is being processed sequentially. While the first sector is being read, the
CPU cannot process that information and so must wait or find something else to do
in the meantime. Once the first sector is read, the CPU can start processing while
the disk drive (in parallel) begins reading the second sector. If the time required for
the CPU to process a sector is approximately the same as the time required by the
disk controller to read a sector, it might be possible to keep the CPU continuously
fed with data from the file. The same concept can also be applied to output, writing
one sector to disk while the CPU is writing to a second output buffer in memory.
Thus, in computers that support double buffering, it pays to have at least two input
buffers and two output buffers available.
Caching information in memory is such a good idea that it is usually extended
to multiple buffers. The operating system or an application program might store
many buffers of information taken from some backing storage such as a disk file.
This process of using buffers as an intermediary between a user and a disk file is
called buffering the file. The information stored in a buffer is often called a page,
and the collection of buffers is called a buffer pool. The goal of the buffer pool
is to increase the amount of information stored in memory in hopes of increasing
the likelihood that new information requests can be satisfied from the buffer pool
rather than requiring new information to be read from disk.
As long as there is an unused buffer available in the buffer pool, new informa-
tion can be read in from disk on demand. When an application continues to read
new information from disk, eventually all of the buffers in the buffer pool will be-
come full. Once this happens, some decision must be made about what information
in the buffer pool will be sacrificed to make room for newly requested information.
When replacing information contained in the buffer pool, the goal is to select a
buffer that has “unnecessary” information, that is, the information least likely to be
requested again. Because the buffer pool cannot know for certain what the pattern
of future requests will look like, a decision based on some heuristic, or best guess,
must be used. There are several approaches to making this decision.
One heuristic is “first-in, first-out” (FIFO). This scheme simply orders the
buffers in a queue. The buffer at the front of the queue is used next to store new
information and then placed at the end of the queue. In this way, the buffer to be
replaced is the one that has held its information the longest, in hopes that this in-
formation is no longer needed. This is a reasonable assumption when processing
moves along the file at some steady pace in roughly sequential order.
However,
