The specs for Ass03 might be a bit vague

The specs for Ass03 might be a bit vague on what is really required. This is done
purposefully to allow you to express yourself. However, this also may leave some of
you wondering with is actually the correct way to do something. Below are some
pointers for “doing it right” or to put it another way, what I’ll be looking for to give/take
off marks!Objective #1The main aim of the game here is to move a long-running task of the Event
Dispatching Thread (EDT). The easiest way to do this the “right way” is to create a
class that extends the SwingWorker and use the SwingWorker framework to execute
the long running task and communicate between the task and the EDT (which the
GUI is updated on). There are other safe ways to do this but the SwingWorker is
there for a reason so why not use it (although this can make communication between
the worker thread, the long running task (life), and the GUI a bit more trickier
If you break away from the rules, I will start deducting marks. The 2 big rules are
(see lectures):
1) do NOT execute long running tasks on the EDT
2) do NOT update GUI elements from threads other than the EDT
In Java/Swing, these rules are not enforced, but you should try to stick by them (at
least if you want marks for the assignment). If you do not know how to follow rule 2,
then I suggest you watch the lectures.Objective #2This is where you get to make the life go faster (hopefully).
Here you can try out some other threading ideas. You can use Thread, Runnable,
Thread Pools, even a ForkJoinPool and RecursiveTask/Actions if you think it works
for you (if you don’t know what they are…watch the lectures).
The generation that is being simluated tests that each square (an x,y location) in the
bound of life fits the current rules for Birth and Survival – this is what the main chunk
(the part inside the loops) of the compute_java_single method does in the
LifeProcessor class. Each square is independent of the other squares so this is an
embarrasingly parallel problem, e.g. you could have a thread for each x,y square in
the life grid. However, you probably don’t have that many cores (real threads) at
your disposal so you need to manage your threads smartly. The smarter you
manage your threads to more marks you will get.
For example if you created and started an independent thread for every square you
would get marked down as this would create a massive overhead and probably be
slower than your serial version (although it might make a good comparison for
objective #3 if you have the time to come up more than one solution There is more than one “right” answer to objective #2. You need to carefully thinkabout the problem and how best to parallelise it. This is what makes this part hard!!!
Basically, you have an x,y grid and you need to divide it up into a number of good
sized chuck to be solved (conquered) in parallel – noting that the best number of
threads may change depending on what hardware it runs on (e.g. hard-coding 4
threads might be a bit short sighted)…I may run your code on Colossus with 32
Do not forget that you also need to be able to communicate progress back to the
GUI (via the EDT) and also be able to cancel (stop nicely) your thread from the GUI
(EDT).Objective #3Hhopefully, this part should be straight forward…Marking SchemeMy marking scheme is vaguely (which actually aligns with Uni policy)
P => getting most of it working
CR => getting all* of it working
DN => getting all* of it working and doing it the “correct” way
HD => getting all* of it working and doing it the “correct” way and going beyond
*you can achieve this levels without all working if the bits that do are beyond
Hope that helps!

Assignment status: Already Solved By Our Experts

( USA, AUS, UK & CA  PhD. Writers )


Leave a Reply

Your email address will not be published. Required fields are marked *