Java Reference
In-Depth Information
A variation on this approach is to have the getblock function take another
parameter to indicate the “mode” of use for the information. If the mode is READ
then the buffer pool assumes that no changes will be made to the buffer's contents
(and so no write operation need be done when the buffer is reused to store another
block). If the mode is WRITE then the buffer pool assumes that the client will not
look at the contents of the buffer and so no read from the file is necessary. If the
mode is READ AND WRITE then the buffer pool would read the existing contents
of the block in from disk, and write the contents of the buffer to disk when the
buffer is to be reused. Using the “mode” approach, the dirtyblock method is
avoided.
One problem with the buffer-passing ADT is the risk of stale pointers. When
the buffer pool user is given a pointer to some buffer space at time T1, that pointer
does indeed refer to the desired data at that time. As further requests are made to
the buffer pool, it is possible that the data in any given buffer will be removed and
replaced with new data. If the buffer pool user at a later time T2 then refers to the
data referred to by the pointer given at time T1, it is possible that the data are no
longer valid because the buffer contents have been replaced in the meantime. Thus
the pointer into the buffer pool's memory has become “stale.” To guarantee that a
pointer is not stale, it should not be used if intervening requests to the buffer pool
have taken place.
We can solve this problem by introducing the concept of a user (or possibly
multiple users) gaining access to a buffer, and then releasing the buffer when done.
We will add method acquireBuffer and releaseBuffer for this purpose.
Method acquireBuffer takes a block ID as input and returns a pointer to the
buffer that will be used to store this block. The buffer pool will keep a count of the
number of requests currently active for this block. Method releaseBuffer will
reduce the count of active users for the associated block. Buffers associated with
active blocks will not be eligible for flushing from the buffer pool. This will lead
to a problem if the client neglects to release active blocks when they are no longer
needed. There would also be a problem if there were more total active blocks than
buffers in the buffer pool. However, the buffer pool should always be initialized to
include more buffers than should ever be active at one time.
An additional problem with both ADTs presented so far comes when the user
intends to completely overwrite the contents of a block, and does not need to read
in the old contents already on disk. However, the buffer pool cannot in general
know whether the user wishes to use the old contents or not. This is especially true
with the message-passing approach where a given message might overwrite only
part of the block. In this case, the block will be read into memory even when not
needed, and then its contents will be overwritten.
This inefficiency can be avoided (at least in the buffer-passing version) by sep-
arating the assignment of blocks to buffers from actually reading in data for the
Search WWH ::




Custom Search