Lecture 9 Exercise:

Open Lecture09VS. It's a demo of a "text file" that has its own controller and is shared by two threads, one which writes the file and one that reads it.  Rebuild and run the demo.

Now, study its class diagram, and match the code to the diagram.  Notice how the  Reader  interface limits the  ReaderForm  to *only* the  readLine  method  (similar for  WriterForm).  Study the  FileController's  code.

There are two problems with the code -- fix them:

I. It is possible for the WriterForm to open the file, and while writing, then the  ReaderForm  opens the same file!   Improve the FileController to enfore *exclusive access* of the file to one thread at a time.   (Use a state variable.)

II. It is possible for the ReaderForm and WriterForm to both ask to open the file at the same instant, like we saw in the "token race example".  Insert lock(s) to prevent this.








======================================

About the exercise: when a resource, like a file, is used in a sequence of transactions, both locks and state variables are needed to manage it.  With these, it is impossible for more than one thread to read/write the file at the same moment in our little "closed" system.

MORE TO DO:

But a public file server is "open" --- other threads can connect to the server and cause trouble.   Let's consider this:

Download and unzip  Lecture09b.   Open  Lec09RMversion2.  Rebuild and start it.  There are two WForms and an RForm.  They are well behaved. (Try 'em.)  But there is also an "Intruder" form that causes trouble by telling the controller (server) to close its file!   (Try it.)
This messes up everything.

TO DO;
(i) study the included class diagram, which proposes a solution.
(ii) implement it and verify that the intruder becomes harmless. 


In general, when a client (e.g., web browser) connects with a public (web) server, it transmits its identity (IP address) and receives in return a key ("nonce") that it uses with its identity in subsequent communications, similar to what we built today.