Concurrency, Threads, Thread safety

in JAVA and SWING

Sibylle Haucke, DWD
EGOWS June 2005, Exeter, UK

Agenda
Concurrency - definition and motivation
Processes and Threads in JAVA
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo

EGOWS 2005: Concurrency

DWD June 2005

Concurrency - literature and links

Jeff Magee and Jeff Kramer - Concurrency -State Models and Java
Programs
John Wiley&Sons July 2003

Doug Lea - Concurrent Programming in Java

Addison Wesley November 2003

Simone Bordet (Senior Java Engineer - simone.bordet@hp.com) :A New

Solution for Using Threads with the Java Foundation Classes (JFC/Swing)
API:The Synchronous Model
- http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
- Yexin Chen: Customize SwingWorker to improve Swing GUIs
- http://www.javaworld.com/javaworld/jw-06-2003/swingworker/jw-0606swingworker.jar
- http://www.javaworld.com/javaworld/jw-06-2003/jw-0606swingworker_p.html#resources
- http://sourceforge.net/projects/spin/
http://foxtrot.sourceforge.net/

EGOWS 2005: Concurrency

DWD June 2005

What is a Concurrent Program?

A sequential program has a
single thread of control.
A concurrent program has
multiple threads of control
allowing it perform multiple
computations in parallel and to
control multiple external
activities which occur at the
same time.

EGOWS 2005: Concurrency

DWD June 2005

Why Concurrent Programming?

Performance gain from multiprocessing hardware
 parallelism.

Increased application throughput

 an I/O call need only block one thread.

Increased application responsiveness

 high priority thread for user requests. ( see SWING and Threads )

More appropriate structure

 for programs which interact with the environment, control multiple activities and
handle multiple events.

EGOWS 2005: Concurrency

DWD June 2005

Concurrent Execution
A

Concurrency

B
C

 Logically simultaneous processing.

 Does not imply multiple processing elements (PEs).
 Requires interleaved execution on a single PE.

Time

Parallelism
 Physically simultaneous processing.
 Involves multiple PEs and/or independent device operations.

Both concurrency and parallelism require controlled access

to shared resources
We use the terms parallel and concurrent interchangeably
and generally do not distinguish between real and pseudoconcurrent execution.
EGOWS 2005: Concurrency

DWD June 2005

Implementing processes - the OS view

O S Proc ess
D ata

Code

D escriptor

Stack

Stack

D escriptor

D escriptor

D escriptor

T hread 1

T hread 2

Thread n

Stack

A (heavyweight) process in an operating system is represented by its code,

data and the state of the machine registers, given in a descriptor. In order to
support multiple (lightweight) threads of control, it has multiple stacks, one
for each thread.
EGOWS 2005: Concurrency

DWD June 2005

Agenda
Concurrency - definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo

EGOWS 2005: Concurrency

DWD June 2005

Do I need to know about a correct

concurrent design ?
Concurrency is widespread but error prone.

EGOWS 2005: Concurrency

DWD June 2005

The Interference problem

execution of the instructions from a set of threads can be interleaved in
an arbitrary fashion
this interleaving can result in incorrect updates to the state of a shared
object - the phenomenon is known as interference
a simple example will show, how the problem occurs and how to deal
with it - the ornamental garden (Alan Burns and Geoff Davis 1993)
what happens, if 2 threads have access to one object
lets see..

EGOWS 2005: Concurrency

DWD June 2005

Safety failures: Ornamental garden

People enter an ornamental garden through either of two turnstiles.
Management wish to know how many are in the garden at any time
The concurrent program consists of two concurrent threads and a
shared counter object.

Garden

West
Turnstile

EGOWS 2005: Concurrency

people

East
Turnstile

DWD June 2005

Ornamental garden
Uses Objects of classes Turnstile and Counter
Each Turnstile is a separate Thread
...
...
class
class Turnstile
Turnstile extends
extends Thread
Thread {{
NumberCanvas
NumberCanvas display;
display;
Counter
people;
Counter people;
Turnstile(NumberCanvas
Turnstile(NumberCanvas n,Counter
n,Counter c)
c)
{{ display
=
n;
people
=
c;
}
display = n; people = c; }
public
public void
void run()
run() {{
try{
try{
display.setvalue(0);
display.setvalue(0);
for
for (int
(int i=1;i<=Garden.MAX;i++){
i=1;i<=Garden.MAX;i++){
Thread.sleep(500);
Thread.sleep(500); //0.5
//0.5 second
second between
between
arrivals
arrivals
display.setvalue(i);
display.setvalue(i);
people.increment();
people.increment();
}}
}} catch
catch (InterruptedException
(InterruptedException e)
e) {}
{}
}}
}}
EGOWS 2005: Concurrency

DWD June 2005

Ornamental garden - Counter class

class
class Counter
Counter {{
int
int value=0;
value=0;
NumberCanvas
NumberCanvas display;
display;
..
..
..

}}

void
void increment()
increment() {{
int
int temp
temp == value;
value; //read
//read value
value
Simulate.HWinterrupt();
Simulate.HWinterrupt();
value=temp+1;
//write
value=temp+1;
//write value
value
display.setvalue(value);
display.setvalue(value);
}}

EGOWS 2005: Concurrency

DWD June 2005

Ornamental garden - display

After the East and West turnstile threads have each incremented its
counter 20 times, the garden people counter is not the sum of the
counts displayed.
Counter increments have been lost.

EGOWS 2005: Concurrency

Why?

DWD June 2005

Concurrent method invocation in Java interference

Java method activation is not atomic - thread objects east and west
may be executing the code for the increment method at the same time.

west
PC

shared code

east
PC

increment:
program
counter

read value

program
counter

write value + 1

EGOWS 2005: Concurrency

DWD June 2005

Interference and Mutual Exclusion

most common way to solve this: make the public actions
atomic, that such actions runs to completion without
interference from others
Solution in this example:
declare the method increment synchronized
synchronized makes the method atomicthe second Thread, that wants to access the method,
is blocked until the first has left (released) the
method.

EGOWS 2005: Concurrency

DWD June 2005

Ornamental garden mutual exclusion

class
class Counter
Counter {{
..
..
..

}}

synchronized
synchronized void
void increment()
increment() {{
int
temp
=
value;
int temp = value; //read
//read value
value
Simulate.HWinterrupt();
Simulate.HWinterrupt();
value=temp+1;
//write
value=temp+1;
//write value
value
display.setvalue(value);
display.setvalue(value);
}}

EGOWS 2005: Concurrency

DWD June 2005

Synchronize everything - a solution?

Usage of synchronized has to do be done carefully:
Thread deadlocks are possible, if several Threads block
each other by waiting on the release of methods/objects by
each other
to synchronize all methods would also lead to poor
performance
danger:
system deadlock = no further progress

EGOWS 2005: Concurrency

DWD June 2005

Dining Philosophers
Five philosophers sit around a
circular table. Each philosopher
spends his life alternately thinking
and eating. In the centre of the table
is a large bowl of spaghetti. A
philosopher needs two forks to eat a
helping of spaghetti.
One fork is placed between each pair
of philosophers and they agree that
each will only use the fork to his
immediate right and left.

EGOWS 2005: Concurrency

DWD June 2005

Dining Philosophers
Each FORK is a shared
resource with actions get
and put.
When hungry, each PHIL
must first get his right and
left forks before he can
start eating.

right

FORK

phil[0]:
PHIL

lef t

right

lef t

phil[4]:
PHIL

phil[1]:
PHIL

lef t

right

FORK

FORK

right

lef t

phil[2]:
PHIL

EGOWS 2005: Concurrency

FORK

right

FORK

lef t

phil[3]:
PHIL

DWD June 2005

Dining Philosophers - deadlock

This is the situation where all the
philosophers become hungry at the
same time, sit down at the table and
each philosopher picks up the fork to
his right.
The system can make no further
progress since each philosopher is
waiting for a fork held by his
neighbour i.e. a wait-for cycle
exists!

EGOWS 2005: Concurrency

Trace to DEADLOCK:
phil.0.sitdown
phil.0.right.get
phil.1.sitdown
phil.1.right.get
phil.2.sitdown
phil.2.right.get
phil.3.sitdown
phil.3.right.get
phil.4.sitdown
phil.4.right.get

DWD June 2005

Deadlock-free Philosophers
Deadlock can be avoided by ensuring that a wait-for cycle
cannot exist. How?
Introduce an asymmetry into our definition of philosophers.
Use the identity I of a philosopher to make even numbered
philosophers get their left forks first, odd their right first.

EGOWS 2005: Concurrency

DWD June 2005

Safety and liveliness

Two complementary sets of correctness concerns:
safety :

nothing bad happens to an object: ensure consistent object states

safety failure: things start going wrong
liveliness :

something good eventually happens within an activity : making

progress, no deadlocks

liveliness failure: things stop running

common engineering priority: safety ( better nothing happens than
something dangerous)
due to efficiency issues often the selectively sacrifying safety for
liveness is done, example: it may be acceptable for visual displays to
show nonsense in between if you are confident that this state of affairs
soon will be corrected.
EGOWS 2005: Concurrency

DWD June 2005

Safety and liveness

Example - SingleLaneBridge
A bridge over a river is only wide enough to permit a single lane of
traffic. Consequently, cars can only move concurrently if they are
moving in the same direction. A safety violation occurs if two cars
moving in different directions enter the bridge at the same time.
liveliness: Does every car eventually get an opportunity to cross the
bridge?

EGOWS 2005: Concurrency

DWD June 2005

Safety
typical failures:(race conditions)
read/write conflicts: 1 thread reads a value of a field, while another
writes it, the value, seen by the reading thread- hard to predict, depends
on, who won the race
write/write conflicts: 2 threads write to the same field, who will win the
race?

Possible results:
 a graphical object is shown on a place , where it never was
 a bank account is incorrect after the attempt to withdraw money in the
midst of an automatic transfer
Build a guaranteed safe system: to arrange that no objects ever
execute any methods, and thus conflicts can never encounter
Not a very productive form of programming
--> safety concerns must be balanced by liveliness concerns

EGOWS 2005: Concurrency

DWD June 2005

Liveliness : activities fail to make progress

liveliness failures:
Normally these are temporary blocks, which are acceptable for a
certain amount of time:
Locking: a synchronized method blocks one thread because another
thread holds the lock
waiting: a method blocks (Object.wait) waiting for an event, message
or condition that has yet to be produced by another thread
input: an IO-based method waits for input from another process/device
CPU contention: CPU is occupied by other threads or separate
programs
Failure: a method running in a thread gets an exception, error or fault

EGOWS 2005: Concurrency

DWD June 2005

Liveliness : permanent lack of progress

Deadlock : circular dependencies among locks
missed signals: a thread started waiting after a notification to wake up
was produced
nested monitor lockouts: a waiting thread holds a lock that would be
needed by any other thread to wake it up
Livelock: a continuously retried action continuously fails
Starvation: the JVM(OS fails ever to allocate CPU time to a thread
(scheduling policies)
resource exhaustion: finite number of resources : a group of threads
try to share, one of them needs additional resources, but no other gives
one up
distributed failure: a remote machine, connected by a socket serving
InputStream crashes

EGOWS 2005: Concurrency

DWD June 2005

Agenda
Concurrency - definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo

EGOWS 2005: Concurrency

DWD June 2005

Safe concurrent design - rules

a type checked program might not be correct, but does not do any
dangerous things (like misinterpret a float value as an object)
similarly a safe concurrent design might not have the intended effect,
but at least it never encounters errors due to corruption of
representations by contending threads
type safety can be checked by compilers
multithreaded safety cannot be checked automatically, but must rely on
programmers discipline !!
Needs careful engineering practices
 main goal: consistent state of all objects ( and their fields)
 All fields of all objects must have meaningful and legal states
 hard to find out, what exactly does legal mean in a particular class?

EGOWS 2005: Concurrency

DWD June 2005

Safe concurrent design - How to?

2 general approaches for dealing with context dependence:
1) minimise uncertainty by closing off parts of systems
2) establish policies and protocols that enable components to become
or remain open

EGOWS 2005: Concurrency

DWD June 2005

Safe concurrent design - Open systems

Infinitely extendable,
may load unknown classes dynamically
allows sub classes to overwrite any method
share common resources across threads
use reflection to discover and invoke methods
full static analysis impossible
must rely on documented policies and protocols =design rules

The NinJo Pac client framework is open - is a partial closing of

subsystems (agents) possible?

EGOWS 2005: Concurrency

DWD June 2005

Safe concurrent design - Closed subsystems

Restricted external communication
all interactions inward and outward: through a narrow interface
deterministic internal structure:
the concrete nature (and ideally, number) of all objects and threads
comprising the subsystem are statically known. Keywords final and
private can be used to help enforce this
embedded systems often composed as collections of closed
modules
open / closed systems both are challenging to carry out, but have opposite
effects!

EGOWS 2005: Concurrency

DWD June 2005

Agenda
Concurrency - definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo

EGOWS 2005: Concurrency

DWD June 2005

Why using Threads in SWING driven programs?

all GUI actions start in the Swing Event Thread (inside actionPerformed
or propertyChanged methods)
while running these actions the event thread is blocked
if the event thread is blocked- no repaint (animation) can take place
To perform a time-consuming task without locking up the EDT we need
threads:
examples:
extensive calculations, do something, that results in many classes being
loaded (initialisation)
loading data from network or from huge or lot of files
to wait for messages from clients

EGOWS 2005: Concurrency

DWD June 2005

SWING and Threads :

Basic Swing concepts review
First, when the user interacts with Swing components, whether he/she
is clicking on a button or resizing a window, the Swing toolkit generates
event objects that contain relevant event information, such as event
source and event ID
The event objects are then placed onto a single event queue ordered by
their entry time.
While that happens, a separate thread, called the event-dispatch
thread, regularly checks the event queue's state.
As long as the event queue is not empty, the event-dispatch thread
takes event objects from the queue one by one and sends them to the
interested parties (e.g. event listeners).
Finally, the interested parties react to the event notification by
processing logic such as event handling or component painting.
Next slide illustrates how this works.

EGOWS 2005: Concurrency

DWD June 2005

Swing and Threads : Swing event-dispatch model

user action-> SwingToolkit generates event objects (event source, event
Id,..)

single event queue, events ordered by entry time

EGOWS 2005: Concurrency

DWD June 2005

If using Threads in SWING driven programs You will have to concern about all thread safety issues
in your design !

EGOWS 2005: Concurrency

DWD June 2005

NinJo - an open system

NinJo: PAC client framework is an open system
 you load unknown classes per XML configuration
 reflection is used
 methods can be overwritten
 Infinitely (!) extendable
To introduce Concurrency in such a system now is a challenge !
Why do we have to do this at all?
 One reason is the SWING GUI concept, see next slides
 another reason is:We have event client threads, waiting for being
alarmed from our Automon monitoring system- thus the threads are
already there and we have to deal with concurrency (thread safety)
anyway..

 We want to make profit out of our 2 processor client hardware

EGOWS 2005: Concurrency

DWD June 2005

NinJo - Thread safety design rules

NinJo policies:
Framework safety:
 parts of the frameworks are Closed by using the final and
private keywords

 usage of Template design pattern for correct code sequences AND

thread/job controlling

design rules
 Thread control is done centrally (in Toplevel PAC agents)
 No arbitrary thread creation allowed, jobs are queued for each
Scene(Map) separately, only 1 job is done for each scene at a time

 separation of GUI/Non GUI code in all components is a design rule

Usage of Doug Lea classes for the thread/job control itself

EGOWS 2005: Concurrency

DWD June 2005

NinJo - Thread per Scene

EGOWS 2005: Concurrency

DWD June 2005

NinJo - Thread per Scene

EGOWS 2005: Concurrency

DWD June 2005