Contents   Index

Read/Write Conflicts

In this section I will look at read/write conflicts, i.e., writes based on or using out-dated data.

Example Scenario

• Bill using client machine no. 1 opens libresolve.a (strict, i.e., $MT \! B$=0) for writing, does his updating (locally), and closes libresolve.a.
• 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., $CT \! B$=0) for reading, read (locally), and closed during the build.

Figure 5.4: 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!

Figure 5.5: 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.

Figure 5.6: 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 $MT \! B$$>$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 $CT \! B$$>$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 availability.

  Contents   Index