COMP0008 Written Java Coursework (2019/20)
NOTE: Your final Moodle submission will consist of a number of parts:
1.Three different versions of the “ConwaysGameOfLife.java” file after different modifications called:
“ConwaysGameOfLife_VERSION1.java”, “ConwaysGameOfLife_VERSION2.java”, “ConwaysGameOfLife_VERSION3.java”.
(Thus you should only modify this file and not create other Java files.)
2.A PDF file giving answers to the questions below (given with bold stars). You can write this description using Word or Latex - as long as you submit a PDF version in the end.
Getting going ...
Take your favourite Java IDE and install: Conway’s Game of Life
From the github:
https://github.com/Burke9077/Conway-s-Game-of-Life.git
(You should be familiar with how to do this.)
This is quite a popular version of the game mentioned in a number of websites … but we are going to analyse its faults and try to improve its structure … in particular focusing on concurrency.
Build the system, run it and play around with the GUI to get a feel for how it works. You should take copies of your Java files after each of these tasks to be submitted to
Moodle. [Also this will enable you to roll back to a previous working version if revisions all
go horribly wrong! Although ideally you would be using a revision control system like git.]
Task 1: To get you familiar with the code.
Choose the File > Options menu to set the rate of the game at 20 frames per second. Choose the Game > Autofill menu item and select 40% random tiles to fill.
Now start the game running … and wait.
Eventually (after a number of minutes) … it will crash with:
*** QUESTION 1: Describe what caused this bug and how you fixed it.
*** Take a copy of your Java code and label it “ConwaysGameOfLife_VERSION1.java”
Task 2: Getting into trouble with concurrency.
It should be clear now that there are two threads running through the GameBoard class. A GUI thread which is painting the squares (and also changing them on mouse
代做COMP0008作业、github留学生作业代写events) together with changing other aspects of the boards (for instance when resizing the board). Also there is a user thread that is calculating how squares change for the next step in the game. It seems the GameBoard class is responsible for too much and it’s sure to end in disaster!
The catching (and then ignoring) of the “ConcurrentModificationException” sort of indicates that we have a concurrency issue here! Add a “System.out.println(“CONCURRENCY ISSUE !!!”)” into the code to see if we ever get this exception actually being thrown:
} catch (ConcurrentModificationException cme) {System.out.println("CONCURRENCY EXCEPTION !!!");}
Running at 20 frames per second with 40% random squares … try changing the board by clicking on it … or resizing the board … minimizing it and maximizing it (causing the repaint method to be called). What you are trying to do is cause the “CONCURRENCY EXCEPTION !!!” message to be displayed. It isn’t easy since it requires the GUI thread and the game thread to collide in terms of accessing or modifying the game squares. But I can produce multiple concurrency exceptions when drawing squares over the board with the mouse button pressed while the game is running:
/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java -javaagent:/home/ucackxb/software/idea- IC-183.4588.61/lib/idea_rt.jar=39515:/home/ucackxb/software/idea-IC-183.4588.61/bin - Dfile.encoding=UTF-8 -classpath /home/ucackxb/COURSES/COMP0008/Conway-s- Game-of-Life_version2/out/production/Conway-s-Game-of-Life ConwaysGameOfLife
CONCURRENCY EXCEPTION !!!
CONCURRENCY EXCEPTION !!! CONCURRENCY EXCEPTION !!! CONCURRENCY EXCEPTION !!!
---
But you can actually get worse than this. By very quickly decreasing the size of the board while it is being recalculated … you can get the user thread crashing out with an ArrayIndexOutofBoundsException:
/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java -javaagent:/home/ucackxb/software/idea- IC-183.4588.61/lib/idea_rt.jar=32797:/home/ucackxb/software/idea-IC-183.4588.61/bin - Dfile.encoding=UTF-8 -classpath /home/ucackxb/COURSES/COMP0008/Conway-s- Game-of-Life_version2/out/production/Conway-s-Game-of-Life ConwaysGameOfLife
CONCURRENCY EXCEPTION !!!
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at
ConwaysGameOfLife$GameBoard.paintComponent(ConwaysGameOfLife.java:229) at java.desktop/javax.swing.Jcomponent.paint(JComponent.java:1074)
---
For something that looks like it “roughly works” … it’s amazing how fragile it really is due to not considering concurrency issues properly! (In fact putting in code that ignores concurrency issues!)
It may also be useful to read Chapter 9 GUI Applications (pages 189-202) of the Brian Goetz book to get familiar with both Swing GUIs and how threads work in the GUI subsystem.
Change the ArrayList used currently for the “state” of the GameBoard to using the concurrent CopyOnWriteArrayList object. Can you now make the system crash by adding points and resizing the window?
*** QUESTION 2: Explain what is the key difference in how the
CopyOnWriteArrayList behaves compared to a normal ArrayList which has probably made all these concurrency issues disappear (be specific about how a particular mechanism used in the code works differently with these two classes).
Task 3: Speed it up challenge!
This part is more challenging and the instructions are less detailed. So you will have to work out how certain aspects need to be structured yourself and also worry about whether your code is thread safe.
We first want to calculate the time it takes to do 100,000 cycles of the board without any sleeping involved.
1.Comment out the sleep statement in the run() method so it runs at maximum speed.
2.Change the structure within the run() method so that it does 100,000 cycles of the board and then finishes automatically.
3.Add “Date” objects (or similar) so that you can print out the time it takes to do the 100,000 cycles in milliseconds.
*** QUESTION 4: Do five runs and write down the different times your system takes to do 100,000 cycles of the game of life (these will not all be shown on the screen
due to not having any sleep time in the code).
Now you probably have a multicore processor and the current system is only making use of a single core since it is running a single thread for all the calculations.
We are going to restructure the code so that a number of threads each do the calculation of one column of the shared board object. We will used the Executors.newFixedThreadPool(4) to carry out the tasks (where we change the number of threads in the pool to see how it affects the overall speed).
Create a FixedThreadPool executor at the top of the GameBoard class with initially 4 threads in the pool.
The restructuring will involve the current run() method creating a new Runnable object, which you should call “BladeRunner”, for each “i” that it iterates over. Each “BladeRunner” object will then do the calculation for that column of the boolean[][] gameBoard – essentially doing the code within the central “i” loop of the current run() method. Each of these “BladeRunner” objects will be queued on the thread pool so that it executes them.
But how to know when the current run() thread (within the GameBoard) can continue the calculations for the next cycle of the board? Well … it should create a CountDownLatch with the number set to the number of columns to calculate (i.e. the number of BladeRunner objects created). This overall thread will then await on this latch before continuing the next cycle. Each “BladeRunner” will then do a single countDown() on this latch at the end of its run method to indicate it has finished. Thus the thread in the GameBoard will only continue once all the columns have been calculated for the current board.
Your challenge is to work out the detail required to get this architecture to work and also to worry about concurrency aspects – where might you need to add volatiles or synchronization? You should be accurate in your analysis and not just add volatiles and synchronization everywhere!
*** Take a copy of your Java code with 4 threads assigned to the thread pool. Label the code: “ConwaysGameOfLife_VERSION3.java”
*** QUESTION 5: Experiment with different numbers of threads used in the thread pool (for example try 1 thread, 2 threads, 4 threads, 6 threads, 8 threads, etc). Each
time record three (or better five) measurements of milliseconds for 100,000 cycles of the board. Work out average / standard deviation of times and produce a table /
graph to show what might be the optimal number of threads for your system.
因为专业，所以值得信赖。如有需要，请加QQ：99515681 或 微信：codehelp