Difference between revisions of "CSC352 Game of Life Homework 1"
(→Requirements) |
(→Tips, tricks, and requirements) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 3: | Line 3: | ||
<bluebox> | <bluebox> | ||
Create a version of what we covered in class on 1/21/17. | Create a version of what we covered in class on 1/21/17. | ||
− | Submit it on Moodle before Tuesday's lecture. | + | Submit it on Moodle before Tuesday's lecture. You can (and are encouraged to) work in pair. If you work in pair, you must spend all the time spent on the homework together with your partner. If working in Pair, submit only 1 set of files with both name in the header. |
</bluebox> | </bluebox> | ||
<br /> | <br /> | ||
Line 10: | Line 10: | ||
==Tips, tricks, and requirements== | ==Tips, tricks, and requirements== | ||
<br /> | <br /> | ||
− | :* | + | :* Code your program for only two threads. |
− | :* The two threads | + | :* Try to put your complete code in one file, but several files is Ok if having separate files for your classes helps your design process. |
+ | :* Document your code well! | ||
+ | :* The two threads should be running identical code. | ||
+ | :* Use BlockingQueues for the threads to talk to each other. | ||
:* The manager displays only the last generation. No need for the manager to synchronize itself with the workers every generation. This will make it simpler to code. | :* The manager displays only the last generation. No need for the manager to synchronize itself with the workers every generation. This will make it simpler to code. | ||
+ | :* Since the manager waits for the threads to finish all their generations before displaying the last generation, the manager can '''join()''' the threads, or you can use a queue between workers and manager to indicate that both threads are done. | ||
:* Since the threads need to share the dish arrays (and maybe other arrays or variables), one good way to share the array of strings is to put it in a static class, as follows: | :* Since the threads need to share the dish arrays (and maybe other arrays or variables), one good way to share the array of strings is to put it in a static class, as follows: | ||
<br /> | <br /> | ||
Line 31: | Line 35: | ||
} | } | ||
</source> | </source> | ||
− | :The class '''data''' can be declared in the same file that contains the public manager class, as well as the thread class. | + | :The class '''data''' can be declared in the same file that contains the public manager class, as well as the thread class. It doesn't need to be passed to the threads, since it is static and lives in a static class, in shared memory. |
:Whenever a thread needs to access the dish array, it can just access <tt>data.dish</tt>, as illustrated below, with the inner loop of the life() function: | :Whenever a thread needs to access the dish array, it can just access <tt>data.dish</tt>, as illustrated below, with the inner loop of the life() function: | ||
<br /> | <br /> | ||
Line 50: | Line 54: | ||
</source> | </source> | ||
<br /> | <br /> | ||
+ | |||
+ | =Testing= | ||
+ | <br /> | ||
+ | Figure out a way to test your application and make sure for your threaded game outputs the correct last generation. | ||
+ | <br /> | ||
+ | <br /> | ||
+ | |||
+ | =Code for Reuse= | ||
+ | <br /> | ||
+ | ::* [[CSC352_Game_of_Life_Lab_2017| Game of Life]] | ||
+ | ::* [[CSC352: Using BlockingQueues| Using blocking queues]] | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | <br /> | ||
+ | [[Category:CSC352]][[Category:Java]][[Category:Threads]][[Category:Threading]] |
Latest revision as of 17:41, 21 February 2017
--D. Thiebaut (talk) 15:27, 21 February 2017 (EST)
Create a version of what we covered in class on 1/21/17. Submit it on Moodle before Tuesday's lecture. You can (and are encouraged to) work in pair. If you work in pair, you must spend all the time spent on the homework together with your partner. If working in Pair, submit only 1 set of files with both name in the header.
Contents
Implement a Threaded version of the Game of Life in Java
Tips, tricks, and requirements
- Code your program for only two threads.
- Try to put your complete code in one file, but several files is Ok if having separate files for your classes helps your design process.
- Document your code well!
- The two threads should be running identical code.
- Use BlockingQueues for the threads to talk to each other.
- The manager displays only the last generation. No need for the manager to synchronize itself with the workers every generation. This will make it simpler to code.
- Since the manager waits for the threads to finish all their generations before displaying the last generation, the manager can join() the threads, or you can use a queue between workers and manager to indicate that both threads are done.
- Since the threads need to share the dish arrays (and maybe other arrays or variables), one good way to share the array of strings is to put it in a static class, as follows:
class data { static String[] dish= { " ", " # ", " # # ### ", " ## ", " ", " # ", " # # ", " ## ", " ", " " }; }
- The class data can be declared in the same file that contains the public manager class, as well as the thread class. It doesn't need to be passed to the threads, since it is static and lives in a static class, in shared memory.
- Whenever a thread needs to access the dish array, it can just access data.dish, as illustrated below, with the inner loop of the life() function:
for ( int j=i-1; j<=i+1; j++ ) { // make sure we wrap around from left to right int realj = j; if ( j==-1 ) realj = data.dish[row].length()-1; if ( j==data.dish[row].length() ) realj = 0; if (r==row && j==i ) continue; // current cell is not its // neighbor if (data.dish[realr].charAt(realj) == '#' ) neighbors++; }
Testing
Figure out a way to test your application and make sure for your threaded game outputs the correct last generation.
Code for Reuse