Java Concurrency

Dec 8, 2021
 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 #2
 Asynchronous processes may be running simultaneously, on
different cores, or they may be sharing time on the same core

2
 Problems
 Concurrency introduces the following hazards:
 Race conditions—if two or more processes try to write to the
same data space, or one tries to write and one tries to read, it
is indeterminate which happens first

 Deadlock—two or more processes are each waiting for data

 Livelock—two or more processes each repeatedly change

3
 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();

4
 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 private or final
 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

5
 The synchronized statement
 Synchronization is a way of providing exclusive access to data
 You can synchronize on any Object, of any type
 If two Threads try to execute code that is synchronized on the
same object, only one of them can execute at a time; the other
has to wait
 synchronized (someObject) { /* some code */ }
 This works whether the two Threads try to execute the same block of
code, or different blocks of code that synchronize on the same object
 Often, the object you synchronize on bears some relationship to
the data you wish to manipulate, but this is not at all necessary

6
 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

7
 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
 Atomic actions
 An operation, or block of code, is atomic if it happens “all at once,” that is, no other
Thread can access the same data while the operation is being performed
 x++; looks atomic, but at the machine level, it’s actually three separate operations:
1. load x into a register
2. add 1 to the register
3. store the register back in x
 Suppose you are maintaining a stack as an array:
void push(Object item) {
this.top = this.top + 1;
this.array[this.top] = item;
}
1. You need to synchronize this method, and every other access to the stack, to make the
push operation atomic
1. Atomic actions that maintain data invariants are thread-safe; compound (non-atomic)
actions are not
2. This is another good reason for encapsulating your objects
 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
10
 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!

11
 Local variables
 A variable that is strictly local to a method is thread-safe
 This is because every entry to a method gets a new copy of that variable
 If a variable is of a primitive type (int, double, boolean, etc.) it
is thread-safe
 If a variable holds an immutable object (such as a String) it is
thread-safe, because all immutable objects are thread-safe
 If a variable holds a mutable object, and there is no way to access
that variable from outside the method, then it can be made
thread-safe
 An Object passed in as a parameter is not thread-safe (unless immutable)
 An Object returned as a value is not thread-safe (unless immutable)
 An Object that has references to data outside the method is not thread-safe
 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

13
 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

14
 Advice
 Any data that can be made immutable, should be made immutable
 This applies especially to input data--make sure it’s completely read in
before you work with it, then don’t allow changes
 All mutable data should be carefully encapsulated (confined to the
class in which it occurs)
 All access to mutable data (writing and reading it) must be
synchronized
 All operations that modify the state of data, such that validity
conditions may be temporarily violated during the operation, must
be made atomic (so that the data is valid both before and after the
operation)
 Be careful not to leave Threads running after the program finishes
 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
The End