To be updated.
Instructors: Sun Jun (sunjun@sutd) and Sudipta Chattopadhyay (sudipta_chattopadhyay@)
- Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea
- Problem set * 10: 20%
- Quiz * 5: 10%
- Final Exam: 30%
- Project: 40%
For 50.003-CI01, the cohort classes take place on Mondays 9:30AM – 11:00AM; Tuesday 3:00PM – 4:30PM; and Thursday 9:00AM – 11:00AM.
For 50.003-CI02, the cohort classes take place on Mondays 11:00AM – 12:30AM; Tuesday 1:00PM – 2:30PM; and Thursday 1:00PM – 3:00PM.
|Week||Cohort Class 1||Cohort Class 2||Cohort Class 3||Remarks|
|1 (Jan 23)||Software Development Process|
|2 (Jan 31)||Holiday||Software Design and UML||Problem Set 1|
|3 (Feb 6)||Design Patterns||Project Meeting I||Problem Set 2; Quiz 1|
|4 (Feb 13)||Software Testing||Problem Set 3|
|5 (Feb 20)||Introduction to Concurrency: Sockets and Threads||Problem Set 4; Quiz 2|
|6 (Feb 27)||Thread Control and Safety||Project Meeting II||Problem Set 5|
|7 (Mar 6)||Recess|
|8 (Mar 13)||Composing Thread-safe Objects||Problem Set 6; Quiz 3|
|9 (Mar 20)||Building Blocks||Problem Set 7|
|10 (Mar 27)||Tasks and Thread Pools||Project Meeting III||Problem Set 8; Quiz 4|
|11 (Apr 3)||Concurrency Pitfalls and Testing||Problem Set 9|
|12 (Apr 10)||Performance||Problem Set 10; Quiz 5|
|13 (Apr 17)||Final Project Presentation (15 minutes for each group)||Project Report/Code Due|
|14 (Apr 27)||Final Exam|
* Quiz takes places at the end of the first cohort class of the respective week for 50.003-CI01 and the beginning of the first cohort class for 50.003-CI02. It is paper-based.
* Problem sets are always due Monday midnight the following week. Submissions are via eDimension.
Week 1 (Jan 25, 2016): Introduction to Software Development Process
Week 2 (Feb 1, 2016): Introduction to Software Design and UML
- Problem Set 1 (due Monday midnight the following week)
- Reference: OMG’s official UML 2.5 Specification
Week 3 (Feb 8, 2016): Introduction to Design Patterns
- Problem Set 2 (due Monday midnight the following week)
- (in-class demo code) PassbyValue.java; FactoryPatternDemoOriginal.java; FactoryPatternDemo.java; PizzaStore.java; RobotGame.java; iSubject.java; Observer.java; StockGrabber.java; StockObserver.java; DecoratorDemoOriginal.java; DecoratorDemo.java; VisitorPatternOriginal.java
Week 4 (Feb 15, 2016): Introduction to Concurrency and Socket
- Problem Set 3 (due Monday midnight the following week)
- (in-class demo code) EchoServer.java; EchoClient.java; UDPServerExample.java; UDPClientExample.java; SocketTimeout.java
Week 5 (Feb 22, 2016): Basics of Thread
- Problem Set 4 (due Monday midnight the following week)
- (in-class demo code) Matrix.java; HelloWorldThread.java; RunnableExample.java; ThreadArrayExample.java; SleepExample.java; InterruptExample1.java; InterruptExample2.java
Week 6 (Feb 29, 2015): Thread Safety and Synchronization
- Problem Set 5 (due Monday midnight the following week)
- (in-class demo code) FirstBlood.java; Stack.java; SecondBlood.java; SecondBloodFixed.java; LockStaticVariables.java; ThirdBlood.java; CachedFactorizer.java; Voting.java; BufferExample.java; FactorThread.java; NoVisiability.java; Experiment.java
Week 8 (March 14, 2016): Composing Thread-safe Objects
- Problem Set 6
- (in-class demo code) MyStack.java; MyStackThreadSafe.java; PersonSet.java; Tracker.java; DelegatingTracker.java; PublishingTracker.java; Range.java; MyList.java; BetterVector.java; ExtendedPair.java; ExtendedPairWrong.java; ListHelper.java; ImprovedList.java; FirstExample.java
Week 9 (Mar 21, 2016): Building Blocks
- Problem Set 7
- (in-class demo code) WorkerThread.java; GDesktopProb.java; BarrierExample.java; SemaphoreExample.java; BoundedHashSetQ.java; CountDownLatchExample.java; PhaserExample.java; FutureTaskExample.java; FutureTaskExample2.java; Cache.java; CacheV1.java; CacheV2.java
Week 10 (Mar 28, 2015): Tasks and Thread Pools
- Problem Set 8
- (in-class demo code) MultipleClient.java; MultipleBatchClient.java; WebServer.java; ExecutorWebServer.java; SequentialExecutorWebServer.java; ThreadPerTaskExecutorWebServer.java; LifeCycleWebServer.java
Week 11 (Apr 4, 2016): Concurrency Pitfalls and Testing
- Problem Set 9
- (in-class demo code) DiningPhil.java; DemonstrateDeadlock.java; DLExample.java; TransferFixed.java; DLExampleFixed.java; BoundedBuffer.java; BoundedBufferWithSpec.java; BoundedBufferTest.java; PutTakeTest.java; TestThreadPoolSample.java; TimedPutTakeTest.java; LifeCycleWebServer.java; FutureRenderer.java; ParallelRecursive.java; GDesktop.java
Week 12 (Apr 11, 2016): Performance and Patterns; Non-blocking Algorithms
- Problem Set 10
- (in-class demo code) Exercise1.java; SlidingGame.java; PerformanceExperiment.java; StripedMap.java; SimulatedCAS.java; CasNumberRange.java; ConcurrentStack.java; LinkedQueue.java; NonblockingCounter.java; CasCounterTest.java
- Grouping: The groups are formed using computer algorithms and the groups cannot be changed (unless you have medical proof that you are allergic to certain group member). You may be stuck with someone who you don’t appreciate. Take that as a test of your people skill. Talk to us if there are issues that you can’t deal with. Kindly find your group number HERE.
- Project: Each group is expected to developed an app in the Android platform. My recommendation is that it should be a game which supports multiple users playing concurrently. The scenario is that a group of you, each has an Android device which has the APP installed, can start a game whenever multiple players are ready to have some fun. You may use one of the devices as the server or you can leverage on Google Play Game Service. It is perhaps not a good design if each player must wait for his/her turn to play. You, as a group, will (A) identify the system requirements (e.g., what are the features of the game, how users interact, etc.); (B) come up with the design of the system (e.g., what are the components in the system implementation and how do they communicate, etc.); (C) implement the game; (D) and apply proper techniques so that the system functions properly and reliably. It is possible if you, as a group, decide to develop something other than a game, you are required to communicate early with me on your project though.
- Final Presentation: In week 13, you will present the final product to the instructors and the classmates. You are expected to present.
- the software development process employed in your project;
- a live demo of your app;
- and the hiccups and lessons learned through your project.
- Final Deliverable: You will deliver a self-contained package of the app, including: (A) the code itself; (B) installation and user manuals; (C) a report detailing what are the system requirements, how are the system designed, how are the system evaluated/tested. In particular, we would like to know how you ensure your implementation is thread/safe. (D) a separate report, delivered by individual group member on contribution of every member in the group.
- Presentation and Demonstration of the APP (40%)
Report/Code (60%):Clear documentation of the system requirements (10%);Clear documentation of the system design (15%);Code structure (15%);Clear documentation on how the system is tested (10%);Clear explanation on how concurrency issues are handled or avoided (10%)
The following gives some details on a sample project. Notice that your proposal should be more interesting. The game is a multiplayer variant of the classic computer game “Minesweeper”. You can review the traditional/single-player minesweeper concept / rules here: http://en.wikipedia.org/wiki/Minesweeper_(video_game).
We will refer to the board the board as an NxN grid where each square has a state which can be ‘flagged’, ‘dug’, or ‘untouched’, and each square either has a bomb or does not have a bomb. Our variant works very similarly to real minesweeper but with multiple players for one board. the main functional difference is that when one player blows up a bomb in single player, they just lose. when one player blows up a bomb in our version, they still lose, [i.e. server ends their connection] but the other players may continue playing. The square where the bomb was blown up is now a dug square with no bomb. (The player who lost may also reconnect to the same game.)
Note that there are some tricky cases of user-level concurrency: as a notable example, user A has just modified the game state (i.e. by digging in one or more squares) such that square i,j obviously has a bomb. Meanwhile, user B has not observed the board state since this update has taken place, so user B goes ahead and digs in square i,j. Your program should allow the user to dig in that square– a user of Multiplayer Minesweeper must accept this kind of risk.
The specific components for a game like this include, at the least,
- setting up a server to deal with multiple clients; you should decide what is the best way to handle client requests.
- implementing a data structure for Minesweeper.
- making sure the data structure, which will be updated by multiple clients concurrently perhaps, thread safe.
- putting the server and the clients by defining the protocol for communication so that the system runs robustly.
One particular implementation of the same project is here.
Online Resources/Tutorials on Game Development