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

snottybugbearΛογισμικό & κατασκευή λογ/κού

3 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

97 εμφανίσεις

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