Criteria for Homework 2

Steps Used for Testing

Look at MagicThread.java
Run MagicThread
Run ThreadBank with 6k.tr on saga (to test threading better)
Run ThreadBank 5 times with 100k.tr (to test threading better)
Look at ThreadBank source

Part a (10 points)

The solution was to move the call to new StringBuffer() before starting the threads. Look at the source code and check if the problem has been solved. -2
Check part ii by looking at the source code. The solution was to put Thread.yield() near or inside the while loop. -2
Check part iii by looking at the source code.-2
Check part iv by looking at the source code. See if they have removed the call to new from the synchronized block (the String "+" operator essentially calls new since it creates temp Strings) -2. See if they are doing the concatenation of the strings outside the synchronized block -2. Should use a regular array to hold string, not Vector or ArrayList. An array is guaranteed to be efficient, it's uncertain if ArrayList has to call new -1. Should use StringBuffer instead of String -1. It is not thread safe to concat multiple times to the answer StringBuffer - correct solution used another temporary StringBuffer. While it's true that the StringBuffer is thread safe, this does not mean that multiple calls to append necessarily happen without getting interrupted between calls -3.

Perfect: 10
Each Problem: -2

Part b Thread Bank (45 points)

1) Output (run on sagas). (10) We test for two cases (a) 6k with output changed so that every account get either 999 or 1001. (b) One run on the 100k file. If you didn't print out any output at all, you got nothing.

(a) is worth 5 points if perfect, 0 otherwise
(b) is worth 5 points if perfect, 0 otherwise

If the implementation is serialized so that it's not really running in parallel, then the correct output is only worth 2 in each case instead of 5. We'll ignore little changes in the output, such as reversing the order of the two fields or incuding too much debugging output.

(The order here is written top-down which is what I suspect is the easiest order to look at their code)

2) Thread Launcher / Processor (35)

-Should create, add, run, and remove transaction in a correct and thread safe way (20)

Should notify/wait properly for add ... this should be waiting in a while loop, the problem manifested is deadlock and hanging

The wait() in add should be at the right place. -4
The notify() in add should be at the right place -4. We do not take off for too much notify().

Should aquire/run/release properly. Unnescessary notify -2 per instance.

There should be a wait() in the acquire. -4
There should be a notify() in release. -4. If the call to notify() is not in release but at the end of run, then -2.

The transaction objects should be reused. There shouldn't be calls to new all the time. -4

-Should correctly make the change on both accounts.

Should hold both the locks -4
Should hold the locks in the right order -2. Note that's it's not enough to acquire the "from" lock before the "to" lock, as the following two transactions done at the right time would cause deadlock:

From:1 To:2 Amount:100
From:2 To:1 Amount:100
Should do the transaction. -2

-Should handle the creation of new accounts in accordance with the constraints in the handout...these problems would manifest in slightly deviating results, that weren't always reproducible (10)

Check without the lock [2]
Acquire the single "writelock" [3]. Make sure that the writelock is single and not an instance variable of the worker thread.
Create the account, after checking that still needs to be created [2]

Serialization special case: suppose the code is written so that it actually runs serially. (a) Take off 10 points in the section which introduces the incorrect serialization. (b) grade the other sections for their correctness assuming the code really was being used in parallel. If they are correct, then they still get the points. (c) Running serialized means they don't get most of the ouput points.

Part c: Thread Web (45 points)

Testing Drill

First we run it in a couple obvious ways to see that it parallelizes and interrupts properly. (25)

Run with 4 threads -- hitting the stop button should cause the number of threads to drop pretty quickly
Run with 1 threads -- it should run a lot slower. Interrupt should still work.
Can download content for a URL and compute and display the length = 5
Does the throttling and parallelism properly so the 4x case is much faster than the 1x case = 5
Does the interrupt behavior properly so that the stop button pretty much halts things = 5
The interface should be updated properly -- the buttons, labels, and progress bar need to be updated through the various phases of the download.

The number of threads displayed should never be more than 4 during concurrent fetch and never more than 1 during single fetch (to check throttling). -5
The start button should be enabled only when all the threads have completed download or after pressing stop -5
Any other problem in the updation of the progress bar, labels -5

Source Code (20)

Things to check in the source (this listing is bottom-up, it may be easier to tour the source in the opposite order). It is possible to lose points both in output and source code for the same problem. However, within the source code, you can only lose points for an area once. So for example, if isInterrupted() checking is wrong or deficient, the program loses the points for that once, even though it is spread across several methods. -2 is generally for something minor. -5 corresponds to a single but significant thing not being right.

The WebWorker/WebRow system should check isInterrupted at least twice (checking much more is better) [defficient checking = -2, no checking = -5]
WebWorker.run() should adjust the the text label to +/-1 when it runs and exits. This is to check that the label numbers seen at run-time actually correspond to something. [sligh probs = -2, real problems = -5]
WebWorker should update the row contents if the download was successful and was not interrupted. Whatever is handling the setRow() needs to notify the interface with a fireTableRowsUpdated(). [not short-circuiting on fail/interrupt = -2, real problem with update = -5]
There should be a launching system that uses an independent thread so as to not lock up the whole interface when starting the download process [-5]
launcher thread should fire off independent WebWorker threads but We will allow either the (alloc, start, alloc, start) strategy or, the (alloc alloc start start) strategy. The launcher should be consistent with the strategy for throttling and the strategy for updating the various interface components. [minor problems = -2, major problems = -5]
WebWorker is not on the Swing thread, so it needs to use invokeLater() for the above messages to change the label, and to call setRow() which calls fireTableRowsUpdated(). [failing to use invokeLater where necessary = -5]. Many people put fireXXX inside invokeLater, but left setRow outside the Swing Thread (Actually the fireEvents are written to be SwingThread-safe, so you should never have to call them from within invokeLater). This is still incorrect, since redraws can happen at any time, not only when you do a fireEvent. Imagine that the user is scrolling the table at the exact moment you do a SetRow. This is definitely a violation of the Swing Thread constraint, though we only deducted -3 in this case.
The launcher should wait *before* calling starting the worker. -3. Basically, this means that the throttle.decrement method (whatever semaphore you used for your throttle) needs to happen in the launcher, before you call worker.start(). Many people put the decrement as the first line in worker.run(). This is incorrect, and slightly defeats the purpose of the throttle. Remember the whole point is to limit the amount of resources used to start and execute threads, starting 1000 threads would be expensive still, even if all of those threads immediately went to sleep. Better to wait before threads are started, to save the thread startup costs.

Note: Cap the deductions in source code to 20.