CSE 132 (Spring 2010)
Studio 3: Madeoff Bank Heist and a KWIC GUI

Review studio procedures before starting.

Some guidelines for this week's studio:


  1. Use two computers for this studio, with one open to the studio web page and one for the eclipse workspace.
  2. Load the eclipse workspace using the same directions as you used for studio 1, but use studio3 as the prefix to your studio workspace.
  3. The code from class should appear in the lecture package of the repository.

Madeoff Bank

In this studio, you will find a madeoff package, which contains a version of the Account object you saw in CSE131.

As described in class, the code in this package is not thread safe. Most code is by design, in fact, not thread safe. In this case, the lack of thread safety poses a problem for the bank.

  1. Take a look at the Account object in the madeoff package.
  2. Remind yourself how the methods work:
    Do not change the Account class until told to do so, but do convince yourselves that it works properly.
  3. The Account's sleep() method simulates the passing of time by calling Thread.sleep(int), which causes the thread executing the method to pause for the specified number of milliseconds.
    Such passing of time would happen in the real world on a busy system. We need it here to create the kind of environment in which real applications run.

  4. In the Bank class, you will see a line of code in the runTransactions method:
    transactions[i] = null;  /* FIXME */
    Replace the null with an instance of an anonymous subclass of Thread that overrides its run() method.
    Review your notes from today's lecture and see the extra resources (also posted on the the course calendar):
  5. In the run() method of the anonymous inner class you created, write the following statement:
    acct1.transfer(TRANSFERAMOUNT, acct2);
  6. It is likely that eclipse will show you a problem with your code at this point.
    • The yellow lightbulb can help you out, but...
    • It is important that you understand what you need to do to fix this.
    • Take a look at
    • Ask others around you or a TA to explain what's wrong.
    • Fix this problem by making the appropriate variable final.

  7. This part of the studio is set up so that NUMACCOUNTS Account instances are created, each with INITIALBALANCE funds in them.

    The runTransactions() method executes NUMTRANSACTIONS transactions, each transferring TRANSFERAMOUNT funds from one account to another. The particular accounts are chosen at random. It is possible that the transfer will take place from and into the same account, which is fine.

  8. When the Bank functions correctly and performs only transfers, the following should be true:
    The sum of all of the Accounts' balances should be

  9. Go ahead and run Bank as a Java Application.
    • It's not really over until the Done message is printed (this may take about 15 seconds).
    • What result do you see?
    • Note that for each Thread you create, the code I supplied calls its run method. What does that method do with respect to threads?
  10. Change the line
    What is the difference between .run() and .start()?
  11. Run Bank again as a Java Application.
  12. Qualitatively, how does the program's response time change when you use .start()? Why is it different?
  13. In terms of the output, what do you see? Try running the application many times and describe the behavior.
  14. What you should be seeing is the bad behavior of a race condition, as multiple threads compete for access to the various accounts' balances.
  15. Based on what you learned in class, try to put synchronized on methods in Account to fix this problem:
    1. Most people will first try putting synchronized on all the methods. Try that, and describe what you see.
      • If you get tired of waiting, you can terminate the program by clicking on the red-square stop button.
      • It is important to understand why you see what you see. Look at your notes from class about deadlock.
      • Try to construct a scenario by hand for this program that shows the deadlock.
      • Turn this scenario in on paper as part of the studio.
    2. Try putting synchronized only on boolean transfer(int, Account) since that's the only method we really call. What happens and why?
OK so where should synchronization be placed, and why?

Proceed only if you have time and inclination. You're welcome to try the KWIC GUI part out on your own or later in the semester.

KWIC GUI (time permitting)

As a group, experiment with netbeans to design a GUI for the KWIC lab we did last week.

How should you do this? Design is not something we can do by rote or by formula. This kind of activity requires creativity and a willingness to take risks. Put some crazy ideas out there and brainstorm them as a group.

As a point of reference, I wrote a (let's go with: "straightforward") GUI just to give you an idea of what can be done straightforwardly. I know you can do better.

OK your turn to design a GUI for KWIC. Some notes:

Submitting your work (read carefully)

Last modified 08:59:27 CDT 03 June 2010 by Ron K. Cytron