Assignment: Broken Threads

In this assignment, you will experiment with different ways to create sequences of items using Java Threads. This will give you experience with the challenges of thread-based programming. This will be helpful in understanding some of the concurrency issues you see in the cloud computing labs which will be later in the semester.

Your instructor may have you work in teams of two on this assignment. Check! Generally your instructor will set up a repository for this lab, but there will be no code in the repository.

Assignment Overview

Using multiple threads of execution is a powerful design paradigm that has many benefits when implemented correctly; for example, a well-designed applications can be much more responsive to user input even while carrying out complex activities in the background. However, the risk of using multiple threads is that if there is shared data, both threads can change the shared data at the same time, resulting in that data being set to a bad state. Many Java library classes have warnings about simultaneous access by multiple threads; you probably ignored those warnings because they did not seem relevant. For example, the discussion of ArrayList and HashMap have warnings about concurrent access by multiple threads. To use these classes in multi-threaded applications, the programmer must add constructs to make the code thread-safe.

You will write code to set up various sequences of data (lists, arrays, etc.), each adding data in different ways. This will illustrate common errors that can arise from unsafe, multi-threaded code.

Lab Report Template

As you work through this lab, fill in your findings in the report template. At the top of the template, enter your name(s) and the date. Then, as you complete each experiment, place the requested output for that experiment in the appropriate section. Note that in most cases there will be too much output to show it all; you will be asked to identify portions of the output that illustrate various results and to put just those portions into the report. Be sure to use blank lines to make the report readable. Your instructor will describe how to submit this report and supporting materials.

Assignment details

Part 1

Create a class ThreadingApp within a package threading.part1 and implement it according to the class diagram

The static main will create an instance of ThreadingApp, and the ThreadingApp constructor will create and start a secondary thread. This secondary thread will execute the addElements method. Immediately following the start of the secondary thread, the addElements method should be invoked on the primary thread. When both addElements methods complete, join the secondary thread to the primary thread and output the size of the list, followed by the full contents of the list, to the console. This is illustrated in the following, detailed UML sequence diagram:

In this diagram, the two horizontal brackets on the ThreadingApp timeline indicate code that is executing in parallel. That is, addElements will be called by one thread at the same time it is called in the main thread. However, your solution does not have to follow this diagram in every detail. For example, you might call addElements, start, or join from your main if that seems more natural, but the key is the parallel execution of addElements.

Within the addElements method, implement a for loop that adds a number of integer elements to the list as specified by the count argument. In this lab you will always use 10,000 for the count. We are using the List interface because sometimes you will use ArrayList and others you will use LinkedList. For this first part, you will use ArrayList.

When printing the list, simply use System.out.println(list) (substituting whatever variable you name the list). Do not print each element on its own line, because that will make it very difficult to look at the output.

Run the resulting application several times. Note that it may crash, but does it always crash? Why do you think it crashes? What is the result when it doesn’t crash? Is it what you expect? What is happening? Copy some interesting portions of the the output of the console to your report (described below), and record your observations. Note: do not copy the entire console output (with thousands of values) to your report; select the portions that capture the behavior. Being careful to select the right output is an important part of this assignment.

Some instructors will ask you to demonstrate your solution at this point, but others will not. Check! But also use your common sense; if the instructor is busy, go on to the next part.

Part 2

Create a new package threading.part2. Copy the code from part 1 into this package and then modify your code such that a LinkedList is used instead of an ArrayList. Run the application again several times - the behavior will differ from run to run. Copy the “interesting” console output to your report, review the part 1 questions, and record your observations for the linked list. Focus on explaining why there would be differences between part 1 and part 2.

If requested, demonstrate this to your instructor.

Part 3

Create a new package threading.part3. Copy the code from part 2 into this package. Modify the addElements method, declaring the method synchronized. Note addElements is still called twice, once in the thread and once in main. Run the part 3 code several times. Copy the interesting portion of the console output to your report and record your observations, specifically noting differences in behavior.

If requested, demonstrate this to your instructor.

Part 4

Create a new package threading.part4. Copy the code from part 3 into this package. Remove the synchronized specifier from the addElements method. This time, implement a synchronized block within the addElements method around the collection framework method calls, so just the code that accesses the collection is synchronized. In particular, do not put the synchronization around the entire loop. addElements should still be called twice, once in the thread and once in main. Run the application again several times. Copy the key output from the console to your report and record your observations.

Look closely at your output! If part 4 matches the output of part 3, your implementation has errors that you need to fix. Ask for help if you do not understand what is incorrect! Once you have differences between the output of labs 3 and 4, look closely at the pattern. Understanding part 4’s output will do a lot to help you understand threads.

If requested, commit your code and then demonstrate this to your instructor.

Submission

Commit and push your code to the repository. Then review your lab report, ensuring you have focused your captured output on illustrating the identified issues, ensuring the comments are are clear and reasonably concise, and checking that the data is formatted neatly. Be sure to include a well-reasoned summary explanation of the various behaviors you observed. The explanation should have enough detail that the output was understandable by another student who could not do the assignment because they were ill for a couple weeks. For example, include reasons why the system might crash on some examples, what patterns you see in the runs that do complete, and why the lists followed those patterns.

Acknowledgement

This exercise developed by MSOE faculty. The original version was developed by Dr. M. Hornick, but it has been modified by Drs. J. Yoder and R. Hasker.