80 likes | 164 Views
Another course outline. In chapter 1 we will examine: Frequently used concurrency constructs Conceptual basis for Concurrent OOP (COOP) How concurrency and objects fit together How resulting design forces affect classes and components
E N D
Another course outline In chapter 1 we will examine: Frequently used concurrency constructs Conceptual basis for Concurrent OOP (COOP) How concurrency and objects fit together How resulting design forces affect classes and components How common desgin patterns can be employed to structure solutions
Another course outline (contd.) The three remaining chapters deal the Java concurrency constructs: Exclusion : often using synchronized methods State dependence : often using monitor methods Threads : to establish and manage concurrency
Simple Exclusion Every instance of a Java object possesses a lock. Access to Java locks is through: Synchronized methods, and Synchronized code-blocks – often use this. Both block further concurrent synchronized access to the locked object instance. Unsynchronized methods are not affected.
Some simple locking rules In order to avoid low-level and high-level conflicts when using locking to enforce atomicity with respect to an object: Always lock during updates to object fields. Always lock during access of possibly updated object fields. Never lock when invoking methods on other objects. Too much locking can affect liveness!
The particle applet Lea invites you to embellish this applet. Please do that as part of our first exercise by: Making the particles more attractive / realistic. Providing a mechanism to start or stop the animation. Confining the particles to the canvas. Providing a mechanism to interactively increase the number of particles when the applet is running with non-terminal particles. This should include a particle counter.
The Particle class The role played by the final modifier. Automatically documents a design decision. Method draw() uses a synchronized code-block to access possibly updated object fields. Method draw() releases the lock to invoke the g.drawRect() method. Method move() holds a lock while calling rng.nextInt().
The ParticleCanvas class This class does not create or modify particles, it simply uses them. To do so it will either have to be told about them, or enquire about them. The class uses synchronized methods to protect its copy of the array of particle references. These references are never allowed to be null.
The ParticleApplet The animation is provide by associating a loop with each particle and running each looping action on a thread. Instantiates each thread as an (anonymous) inner class as it captures all the appropriate context variables (p and canvas). Unfortunately these have to be final, Repainting is handled by the Java EventQueue. Threads can be terminated by: Having the run method terminate normally, Interrupting the thread – useful for threads running forever loops. Also good for threads that have invoked Thread.sleep, Thread.join and Object.wait.