Concurrency, Threads, Thread safety Concurrency, Threads, Thread safety in JAVA and SWING in JAVA and SWING

snottybugbearSoftware and s/w Development

Nov 3, 2013 (3 years and 8 months ago)

102 views

Concurrency, Threads, Thread safety
Concurrency, Threads, Thread safety
in JAVA and SWING
in JAVA and SWING
Sibylle Haucke, DWD
EGOWS June 2005, Exeter, UK
DWD June 2005EGOWS 2005: Concurrency
Agenda
Agenda
Concurrency -definition and motivation
Processes and Threads in JAVA
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo
DWD June 2005EGOWS 2005: Concurrency
Concurrency
Concurrency
-
-
literature and links
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
-YexinChen:Customize SwingWorkerto improve Swing GUIs
-http://www.javaworld.com/javaworld/jw-06-2003/swingworker/jw-0606-
swingworker.jar
-http://www.javaworld.com/javaworld/jw-06-2003/jw-0606-
swingworker_p.html#resources
-http://sourceforge.net/projects/spin/
http://foxtrot.sourceforge.net/
DWD June 2005EGOWS 2005: Concurrency
What is a Concurrent Program?
What is a Concurrent Program?
A sequentialprogram has a
single thread of control.
A concurrentprogram has
multiple threads of control
allowing it perform multiple
computations in parallel and to
control multiple external
activities which occur at the
same time.
DWD June 2005EGOWS 2005: Concurrency
Why Concurrent Programming?
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.
DWD June 2005EGOWS 2005: Concurrency
Concurrent Execution
Concurrent Execution
Concurrency

Logicallysimultaneous processing.

Does not imply multiple processing elements (PEs).

Requires interleaved execution on a single PE.
Parallelism

Physicallysimultaneous processing.

Involves multiplePEsand/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 pseudo-
concurrent execution.
A
Time
B
C
DWD June 2005EGOWS 2005: Concurrency
Implementing processes
Implementing processes
-
-
the OS view
the OS view
Data
Code
OS Process
Descriptor
Thread 1Thread 2
Thread n
Stack
StackStack
Descriptor
Descriptor
Descriptor
A (heavyweight) process in an operating system is represented byits 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.
DWD June 2005EGOWS 2005: Concurrency
Agenda
Agenda
Concurrency -definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo
DWD June 2005EGOWS 2005: Concurrency
Do I need to know about a correct
Do I need to know about a correct
concurrent design ?
concurrent design ?
Concurrency is widespread but error prone.
DWD June 2005EGOWS 2005: Concurrency
The Interference problem
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..
DWD June 2005EGOWS 2005: Concurrency
Safety failures: Ornamental garden
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
East
Turnstile
people
DWD June 2005EGOWS 2005: Concurrency
Ornamental garden
Ornamental garden
Uses Objects of classes Turnstile and Counter
Each Turnstile is a separate Thread
...
class Turnstile extends Thread {
NumberCanvas display;
Counter people;
Turnstile(NumberCanvas n,Counter c)
{ display = n; people = c; }
public void run() {
try{
display.setvalue(0);
for (int i=1;i<=Garden.MAX;i++){
Thread.sleep(500); //0.5 second between
arrivals
display.setvalue(i);
people.increment();
}
} catch (InterruptedException e) {}
}
}
...
class Turnstile extends Thread {
NumberCanvas display;
Counter people;
Turnstile(NumberCanvas n,Counter c)
{ display = n; people = c; }
public void run() {
try{
display.setvalue(0);
for (int i=1;i<=Garden.MAX;i++){
Thread.sleep(500); //0.5 second between
arrivals
display.setvalue(i);
people.increment();
}
} catch (InterruptedException e) {}
}
}
DWD June 2005EGOWS 2005: Concurrency
Ornamental garden
Ornamental garden
-
-
Counter class
Counter class
classCounter {
int value=0;
NumberCanvas display;
.
.
.
void increment() {
int temp = value; //read value
Simulate.HWinterrupt();
value=temp+1; //write value
display.setvalue(value);
}
}
classCounter {
int value=0;
NumberCanvas display;
.
.
.
void increment() {
int temp = value; //read value
Simulate.HWinterrupt();
value=temp+1; //write value
display.setvalue(value);
}
}
DWD June 2005EGOWS 2005: Concurrency
Ornamental garden
Ornamental garden
-
-
display
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. Why?
DWD June 2005EGOWS 2005: Concurrency
Concurrent method invocation in Java
Concurrent method invocation in Java
-
-
interference
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.
east
west
increment:
read value
write value + 1
program
counter
PC
PC
shared code
program
counter
DWD June 2005EGOWS 2005: Concurrency
Interference and Mutual Exclusion
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 methodincrement“synchronized”

synchronizedmakes the method atomic-
the second Thread, that wants to access the method,
is blocked until the first has left (released) the
method.
DWD June 2005EGOWS 2005: Concurrency
Ornamental garden
Ornamental garden
-
-
mutual exclusion
mutual exclusion
classCounter {
.
.
.
synchronizedvoid increment() {
int temp = value; //read value
Simulate.HWinterrupt();
value=temp+1; //write value
display.setvalue(value);
}
}
classCounter {
.
.
.
synchronizedvoid increment() {
int temp = value; //read value
Simulate.HWinterrupt();
value=temp+1; //write value
display.setvalue(value);
}
}
DWD June 2005EGOWS 2005: Concurrency
Synchronize
Synchronize
everything
everything
-
-
a solution?
a solution?
Usage ofsynchronizedhas 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 synchronizeall methods would also lead to poor
performance
danger:
system deadlock = no further progress
DWD June 2005EGOWS 2005: Concurrency
Dining Philosophers
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.
0
1
23
4
0
1
2
3
4
DWD June 2005EGOWS 2005: Concurrency
Dining Philosophers
Dining Philosophers
Each FORK is a shared
resourcewith actions get
and put.
When hungry, each PHIL
must first get his right and
left forks before he can
start eating.
phil[4]:
PHIL
phil[1]:
PHIL
phil[3]:
PHIL
phil[0]:
PHIL
phil[2]:
PHIL
FORK
FORK
FORK
FORK
FORK
leftright
right
right
right
left
left
right
left
left
DWD June 2005EGOWS 2005: Concurrency
Dining Philosophers
Dining Philosophers
-
-
deadlock
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!
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 2005EGOWS 2005: Concurrency
Deadlock
Deadlock
-
-
free Philosophers
free Philosophers
Deadlock can be avoided by ensuring that a wait-for cycle
cannot exist. How?

Introduce an asymmetryinto our definition of philosophers.

Use the identity I of a philosopher to make evennumbered
philosophers get their leftforks first, oddtheir right first.
DWD June 2005EGOWS 2005: Concurrency
Safety and liveliness
Safety and liveliness
Two complementary sets of correctnessconcerns:
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 selectivelysacrifyingsafety for
livenessis done, example: it may be acceptable for visual displays to
show nonsense in between if you are confident that this state ofaffairs
soon will be corrected.
DWD June 2005EGOWS 2005: Concurrency
Safety and
Safety and
liveness
liveness
Example
Example
-
-
SingleLaneBridge
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 safetyviolation occurs if two cars
moving in different directions enter the bridge at the same time.
liveliness: Does every car eventuallyget an opportunity to cross the
bridge?
DWD June 2005EGOWS 2005: Concurrency
Safety
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
DWD June 2005EGOWS 2005: Concurrency
Liveliness : activities fail to make progress
Liveliness : activities fail to make progress
liveliness failures:
Normally these are temporaryblocks, which are acceptablefor a
certain amount of time:
Locking: asynchronizedmethod 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
DWD June 2005EGOWS 2005: Concurrency
Liveliness : permanent lack of progress
Liveliness : permanent lack of progress
Deadlock: circular dependencies among locks
missed signals: a thread started waiting aftera 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
DWD June 2005EGOWS 2005: Concurrency
Agenda
Agenda
Concurrency -definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo
DWD June 2005EGOWS 2005: Concurrency
Safe concurrent design
Safe concurrent design
-
-
rules
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 meaningfuland legalstates

hard to find out, what exactly does “legal” mean in a particularclass?
DWD June 2005EGOWS 2005: Concurrency
Safe concurrent design
Safe concurrent design
-
-
How to?
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
DWD June 2005EGOWS 2005: Concurrency
Safe concurrent design
Safe concurrent design
-
-
Open systems
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 NinJoPacclientframeworkis open -is a partial closing of
subsystems (agents) possible?
DWD June 2005EGOWS 2005: Concurrency
Safe concurrent design
Safe concurrent design
-
-
Closed subsystems
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 finaland
privatecan 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!
DWD June 2005EGOWS 2005: Concurrency
Agenda
Agenda
Concurrency -definition and motivation
Thread safe programming: Safety and Liveliness
Safe concurrent design
SWING and Threads in NinJo
DWD June 2005EGOWS 2005: Concurrency
Why using Threads in SWING driven programs?
Why using Threads in SWING driven programs?
all GUI actions start in the Swing Event Thread (insideactionPerformed
orpropertyChangedmethods)
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
DWD June 2005EGOWS 2005: Concurrency
SWING and Threads :
SWING and Threads :
Basic Swing concepts review
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.
DWD June 2005EGOWS 2005: Concurrency
•user action->SwingToolkitgenerates event objects (event source, event
Id,..)
•single event queue, events ordered by entry time
Swing and Threads
Swing and Threads
:
:
Swing event
Swing event
-
-
dispatch model
dispatch model
DWD June 2005EGOWS 2005: Concurrency
If using Threads in SWING driven programs
If using Threads in SWING driven programs
-
-
You will have to concern about all thread safety issues
in your design !
DWD June 2005EGOWS 2005: Concurrency
NinJo
NinJo
-
-
an open system
an open system
NinJo: PAC clientframeworkis 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
DWD June 2005EGOWS 2005: Concurrency
NinJo
NinJo
-
-
Thread safety design rules
Thread safety design rules
NinJo policies:
Framework safety:

parts of theframeworksare “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 (inToplevelPAC 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
DWD June 2005EGOWS 2005: Concurrency
NinJo
NinJo
-
-
Thread per Scene
Thread per Scene
DWD June 2005EGOWS 2005: Concurrency
NinJo
NinJo
-
-
Thread per Scene
Thread per Scene