Java Concurrency - Programming Languages and Techniques II - Lecture Slides, Slides of Programming Languages

Download Java Concurrency - Programming Languages and Techniques II - Lecture Slides and more Slides Programming Languages in PDF only on Docsity!

Java Concurrency

Definitions

 Parallel processes—two or more Threads are running

simultaneously , on different cores (processors), in the

same computer

 Concurrent processes—two or more Threads are

running asynchronously , on different cores (processors),

in the same computer

 Asynchronous means that you cannot tell whether operation A

in Thread #1 happens before, during, or after operation B in

Thread

 Asynchronous processes may be running simultaneously, on

different cores, or they may be sharing time on the same core

Threads

 There are two ways to create a Thread:

 Define a class that extends Thread

 Supply a public void run() method  Create an object o of that class  Tell the object to start: o.start();

 Define a class that implements Runnable (hence it is free to

extend some other class)

 Supply a public void run() method  Create an object o of that class  Create a Thread that “knows” o: Thread t = new Thread(o);  Tell the Thread to start: t.start();

Mutable and immutable objects

 If an object is immutable (cannot be changed), then any number

of Threads may read this object (or different portions of this

object) at any time

 Sun provides a number of immutable objects  You can create an ad hoc immutable object by simply not providing any way to change it  All fields must be final (private may not be enough)  No methods may change any of the object’s data  You must ensure no access to the object until after it is completely constructed

 If an object is mutable (can be changed), and accessible by more

than one Thread, then every access (write or read) to it must be

synchronized

 Don’t try to find clever reasons to think you can avoid synchronization

synchronized methods

 Instance methods can be synchronized:

 synchronized public void myMethod( /* arguments /) { / some statements */ }

 This is equivalent to

 public void myMethod( /* arguments /) { synchronized(this) { / some statements */ } }

 Static methods can also be synchronized

 They are synchronized on the class object (a built-in object that represents the class)

Locks

 When a Thread enters a synchronized code block, it gets

a lock on the monitor (the Object that is used for

synchronization)

 The Thread can then enter other code blocks that are

synchronized on the same Object

 That is, if the Thread already holds the lock on a particular

Object, it can use any code also synchronized on that Object

 A Thread may hold a lock on many different Objects

 One way deadlock can occur is when

 Thread A holds a lock that Thread B wants, and

 Thread B holds a lock that Thread A wants

Check-then-act

 A Vector is like an ArrayList, but is synchronized

 Hence, the following code looks reasonable:

 if (!myVector.contains(someObject)) { // check myVector.add(someObject); // act }

 But there is a “gap” between checking the Vector and adding to it

 During this gap, some other Thread may have added the object to the array  Check-then-act code, as in this example, is unsafe

 You must ensure that no other Thread executes during the gap

 synchronized(myVector) { if (!myVector.contains(someObject)) { myVector.add(someObject); } }

 So, what good is it that Vector is synchronized?

 It means that each call to a Vector operation is atomic

Synchronization is on an object

 Synchronization can be done on any object

 Synchronization is on objects, not on variables

 Suppose you have synchronized(myVector) { … }

 Then it is okay to modify myVector—that is, change the values of its fields

 It is not okay to say myVector = new Vector();

 Synchronization is expensive

 Synchronization entails a certain amount of overhead  Synchronization limits parallelism (obviously, since it keeps other Threads from executing)

 Moral: Don’t synchronize everything!

Thread deaths

 A Thread “dies” (finishes) when its run method finishes

 There are two kinds of Threads: daemon Threads and non-

daemon Threads

 When all non-daemon Threads die, the daemon Threads are automatically terminated  If the main Thread quits, the program will appear to quit, but other non- daemon Threads may continue to run  These Threads will persist until you reboot your computer

 The join(someOtherThread) allows “this” Thread to wait for

some other thread to finish

Communication between Threads

 Threads can communicate via shared, mutable data

 Since the data is mutable, all accesses to it must be synchronized

 Example:

 synchronized(someObj) { flag = !flag; }  synchronized(someObj) { if (flag) doSomething(); }

 The first version of Java provided methods to allow one thread to

control another thread: suspend, resume, stop, destroy

 These methods were not safe and were deprecated almost immediately— never use them!  They are still there because Java never throws anything away  If you want one Thread to control another Thread, do so via shared data

Debugging

 “Debugging can show the presence of errors, but never their

absence.” -- Edgser Dijkstra

 Concurrent programs are nondeterministic: Given exactly the

same data and the same starting conditions, they may or may not

do the same thing

 It is virtually impossible to completely test concurrent programs;

therefore:

 Test the non-concurrent parts as thoroughly as you can  Be extremely careful with concurrency; you have to depend much more on programming discipline, much less on testing  Document your concurrency policy carefully, in order to make the program more maintainable in the future