In this section I will look at read/write conflicts, i.e., writes based on or
using out-dated data.
- Bill using client machine no. 1 opens libresolve.a (strict, i.e.,
=0) for writing, does his updating (locally), and closes
- Joe using client machine no. 2 opens resolve.c for writing, does
his updating (locally) and closes resolve.c. Then he (re-)builds the
program resolve with libresolve.a linked in, thus
libresolve.a is opened (strict, i.e., =0) for reading, read
(locally), and closed during the build.
No read/write conflict
Possibility of conflict:
- No read/write conflict:
If Bill gets all his work done, before Joe starts reading libresolve.a
then everything is fine, i.e., no read/write conflict occurs. This is depicted
in Figure 5.4 (If, contraversely, Joe gets all his work done, before
Bill starts rewriting libresolve.a then there is no read/write conflict
either--Joe used the latest possible update of the library file).
- Read/write conflict:
A read/write conflict occur when Joe starts reading (as a side effect of his
rebuilding of resolve) libresolve.a after Bill has
started--but before he has finished (or before the updated version has reached
the server)--rewriting it, or when Bill starts rewriting while Joe is reading!
Undetectable read/write conflict
Detection of read/write conflict:
- The read/write conflict depicted in Figure 5.5 could be
detected by use of transactions, that is, if Joe had grouped his work into one
transaction that ended after the close of resolve. This is hinted by
the stippled arrow from client 2 to the server at the close(resolve)
command. For now, the system cannot detect conflicts of this type.
- One could argue that to contact the server after closing a file opened
for reading only is not needed, since it does not affect the server, but it
opens up the possibility of detecting some read/write conflicts, i.e., such as
the one depicted in Figure 5.6. Therefore I chose to contact the
server after a "read" close, to report such a situation.
Detectable read/write conflict
Using locks to avoid read/write conflicts:
- Now, if Bill had locked the file for writing (i.e., being pessimistic
using 0) , the open for reading in Figure 5.5 and the open for
reading in Figure 5.6 would have failed, and thus the read/write
conflicts avoided--at the expense of letting Joe wait until Bill had finished!
- If Joe had started reading before Bill started rewriting, then read/write
conflicts could have been avoided if Joe had been pessimistic (i.e., using
0, and thus readlocking libresolve.a).
In other words, the introduction of locks into the system, to some
extent can make up for the lack of such a thing as IOTs--at the expense of some