Algorithms and Data Structures

N.Wirth. Algorithms and Data Structures. Oberon version 29
relatively large blocks once the tape is moving. Similar conditions hold for magnetic disks, where the data
are allocated on tracks with a fixed number of blocks of fixed size, the so-called block size. In fact, a disk
should be regarded as an array of blocks, each block being read or written as a whole, containing typically
2 k bytes with k = 8, 9, … 12.
Our programs, however, do not observe any such timing constraints. In order to allow them to ignore
the constraints, the data to be transferred are buffered. They are collected in a buffer variable (in main
store) and transferred when a sufficient amount of data is accumulated to form a block of the required size.
The buffer's client has access only via the two procedures deposit and fetch:
DEFINITION Buffer;
PROCEDURE deposit (x: CHAR);
PROCEDURE fetch (VAR x: CHAR);
END Buffer.
Buffering has an additional advantage in allowing the process which generates (receives) data to proceed
concurrently with the device that writes (reads) the data from (to) the buffer. In fact, it is convenient to
regard the device as a process itself which merely copies data streams. The buffer's purpose is to provide a
certain degree of decoupling between the two processes, which we shall call the producer and the
consumer. If, for example, the consumer is slow at a certain moment, it may catch up with the producer
later on. This decoupling is often essential for a good utilization of peripheral devices, but it has only an
effect, if the rates of producer and consumer are about the same on the average, but fluctuate at times. The
degree of decoupling grows with increasing buffer size.
We now turn to the question of how to represent a buffer, and shall for the time being assume that data
elements are deposited and fetched individually instead of in blocks. A buffer essentially constitutes a firstin-first-out
queue (fifo). If it is declared as an array, two index variables, say in and out, mark the positions
of the next location to be written into and to be read from. Ideally, such an array should have no index
bounds. A finite array is quite adequate, however, considering the fact that elements once fetched are no
longer relevant. Their location may well be re-used. This leads to the idea of the circular buffer.
in
out
Fig. 1.8. Circular buffer with indices in and out.
The operations of depositing and fetching an element are expressed in the following module, which
exports these operations as procedures, but hides the buffer and its index variables — and thereby
effectively the buffering mechanism — from the client processes. This mechanism also involves a variable n
counting the number of elements currently in the buffer. If N denotes the size of the buffer, the condition
0 ≤ n ≤ N. Therefore, the operation fetch must be guarded by the condition n > 0 (buffer non-empty), and
the operation deposit by the condition n < N (buffer non-full). Not meeting the former condition must be
regarded as a programming error, a violation of the latter as a failure of the suggested implementation
(buffer too small).