Concurrent Programming with Java

1
Concurrent Programmingwith Java
www.cs.utwente.nl/pieter/cdp/
2
Overview

• Some SPIN reminders
• Concurrency in Java Threads
• RMI Remote Method Invocation
• Promela models and Java
• CSP-programming in Java
• Bandera modern Model-Checking approach

3
SPIN properties

• SPIN automatically verifies whether holds,
  where M is a Promela model of a system and
  property ? is stated in some formal notation.
• When verifying the algorithms from Ben Ari
  1990, these properties were
• absence of non-valid endstates (deadlocks)
• other safety properties (assertions)e.g.
  assert(mutex ! 2)
• limited liveness properties, using progress-labels

4
progress weak fairness

• progress-labels to mark states that have to be
  visited in every potentially infinite execution
  cycle
• If SPIN finds an infinite cycle that does not
  pass through a progress-label, SPIN has found a
  cycle in which no progress has been made a
  non-progress cycle.
• Weak fairness condition if an internal action is
  continually enabled then it will eventually be
  executed.
• The weak fairness condition ensures that any
  process that has a transition that remains
  enabled will eventually execute it.

5
Dining philosophers liveness (2)

• Ben-Ari - p. 79 states that the dining
  philosophers problem which uses monitors has a
  starvation problem.
• Can we use SPIN to find this starvation problem?
• NO, not with plain progress-labels.
• The problem is that SPIN only supports weak
  fairness.
• When using monitors, a Philosopher that wants to
  enter a monitor may be inifinitely often enabled,
  but not continuously!
• Consequently, SPIN will mark infinite cycles
  (e.g. where only a single Philosopher gets to
  eat) as non-progress cycles, which would not be
  marked as such in the strong fair case.
• Is there a solution to this problem?
• YES, but not without difficulties.
• We could encode the strong fairness condition a
  LTL property.
• Follow the course System Validation for details.

6
CDP the course

• CDP is heavily based on Ben Ari 1999
• Principles of Concurrent and Distributed
  Programming
• Focus on the low-level algorithms for
  synchronisation of processes.
• Practice of Concurrent Programming in Java is a
  somewhat different matter.
• could be a complete course on its own

7
Threads (1)
P2

• General recipe for multi-threading in Java
• Define a subclass of Thread containing the method
  run which defines the behaviour of the Thread

public class MyThread extends Thread ...
public void run() ...

• Create an object of this Threadsubclass and call
  start (which actually starts the Thread after
  which the JVM will automatically call the defined
  method run)

MyThread tt new MyThread()tt.start()
8
Threads (2)
P2

• public class Thread public static void
  sleep(long millis) public Thread() public
  Thread(String name) public Thread(Runnable
  r) public void setDaemon() public void
  setName(String name) public String
  getName() public void interrupt() public
  void start() public void run() public
  void join() ...

Let the Tread sleep (can be interrupted).
Interrupts a sleeping ofwaiting Thread.
Waits till the Thread has finished(synchronisatio
n on termination).
9
Threads (3)
P2

• Parallel execution of method run
• Statements within run are themselves sequential.
• Each Thread-object is executed in parallel with
  all others.
• Always start a Thread with start run is pure
  callback.
• Most common use subclass of Thread
• Not always possible due to the single inheritance
  of Java.
• Alternative interface Runnable
• Only method to define public void run()
• Thread-constructor Thread(Runnable r)

public class MyRunnableThread extends ...
implements Runnable ...
MyRunnableThread mrt new MyRunnableThread()Th
read tt new Thread(mrt)tt.start()
10
Synchronisation (1)
P2

• Different kinds of thread programming (w.r.t.
  synchronisation)
• unrelated threads
• threads do different things and do not interact
  with each other
• related, but unsynchronised threads
• multiple threads work on different pieces of the
  same data structure (no shared data, no race
  conditions)
• mutually-exclusive threads
• multiple threads work on shared data they should
  not simultaneously modify the same data
• communicating mutually-exclusive threads
• threads have to exchange information the threads
  have to inform (notify) each other when the state
  has been changed.

11
Synchronisation (2)
P2

• Java uses the monitor-mechanism for
  synchronisation
• each Object in Java has an implicit lock
• at most one thread can have the lock on an object
  
• usage synchronized (obj) critical section

public class Account private double credit
0.0 public void transfer(double amount)
credit amount public class ATM extends
Thread private Account account public
ATM(Account account) this.account account
public void run() synchronized
(account) account.transfer(100.0)

12
Synchronisation (3)
P2

• What happens when a Thread t arrives at a
  synchronized-block of an Object x?
• If no other thread has the lock of Object x,
  Thread t will acquire the lock of x and proceed.
• If some other thread has the lock of Object x,
  Thread t will be put in the waiting list of
  Object x.
• What happens when a Thread t leaves a
  synchronized-block of an Object x?
• The lock of Object x will be released and the
  lock will be given randomly to one of the threads
  in the waiting list of Object x.

This means that it is not guaranteed that a
waiting thread will ever get the lock of the
Object on which it is blocked.
13
Synchronisation (4)
P2

• Synchronisation works on Object-level
• Each Object has an associated lock.
• Synchronized-methods (or blocks) make sure that
  only a single Thread can call (or access) such
  method (or block) on the Object.
• So, if there are more Objects of the same class,
  it is possible that different Threads will
  execute the same synchronized methods, but on
  different objects!

14
wait notify (1)
P2

• It often occurs that although a Thread holds the
  lock of an Object, it cannot continue because
  some condition has not been fulfilled.
• Example producer/consumer processes that put/get
  data into / out of some buffer.

public Object getValue() Object val
boolean consumed false while (!consumed)
synchronized (buffer) if (!
buffer.isEmpty()) consumed true
val buffer.getBuffer()
return val
in classConsumer
shared by all producers/consumers
Only Producers can put values into the buffer.
15
wait notify (2)
P2

• Instead of continuously polling whether some
  condition has been satisfied it is better to
  wait and to be waken up when the state has
  actually been modified.
• x.wait() gives up the lock of Object x and
  starts waiting.
• x.notify() wakes up an arbitrary Thread t that
  has started waiting using x.wait().
• x.notifyAll() wakes up all Threads t that have
  started waiting using x.wait().
• The methods x.wait(), x.notify() and
  x.notifyAll() can only be called by a Thread t
  which has the lock on the Object x.

16
wait notify (3)
It is of course better to implement the
wait/notify synchronisation in the Server-class
Buffer.

• The method getValue of class Consumer now becomes

public Object getValue() synchronized
(buffer) while (buffer.isEmpty())
buffer.wait() buffer.notifyAll()
return buffer.getBuffer()
Wait until some Producer has put a value into the
buffer.
Wakes up all threads that are waiting on buffer.

• The method putValue of class Producer might
  become

public void putValue(Object x) synchronized
(buffer) while (buffer.isFull())
buffer.wait() buffer.putBuffer(x)
buffer.notifyAll()
Waits until some Consumer has taken a value out
of the buffer.
Wakes up all threads that are waiting on buffer.
17
Thread states
P2
initial
start
ready
Thread getsits time slice
Thread losestime slice
lock is givento Thread
notify()notifyAll()
wait
waits for lock
running
blocked
waiting
run methodfinished
sleep
time haselapsed
sleeping
A Thread can only be started once if a Thread
has stopped (reached the end of its run), nothing
can happen anymore to the Thread.
stopped
18
Distributed Programming

• Classification non-sequential programs
• parallel single location (using
  threads)communication using shared memory
  (objects)
• distributed (one or) more locations
• Java supports several techniques and technologies
  for distributed programming
• Sockets
• Remote Method Invocation (RMI)
• Servlets
• CORBA
• Enterprise JavaBeans

In P2 Client/Server programming using Sockets.
19
RMI (1)

• RMI Remote Method Invocation
• RMI lets you call a method on a server and pass
  entire objects in and out you can call methods
  on remote objects as if these objects were
  available locally.
• Natural evolution of client/server systems.
• RMI is completely a library feature there is
  nothing in the Java language that was added to
  enable RMI.
• Major goal simple and lightweight (not as
  complex as CORBA)
• RMI itself is built on top of sockets (but your
  code only has to deal with objects)

RMI powerful technique for building large,
complex systems.
20
RMI (2)

• RMI important concepts
• client calls methods on remote objects on the
  server
• server where the remote objects live
• registry knows about the whereabouts of remote
  objects
• Remote interfaces describe services that are
  provided remotely (i.e. by the server).
• extends java.rmi.Remote (interface)
• all methods throw java.rmi.RemoteException
• Remote objects live on the server and can be
  referenced remotely.
• extends java.rmi.UnicastRemoteObject
• constructor thows java.rmi.RemoteException

21
RMI Example (1)
interface

• We develop a simple RMI client/server system,
  where a client obtains the current date from the
  server.
• Remote service.
• The remote service DateServer the interface
  that the server should implements just returns
  the date.

• import java.rmi.import java.util.Datepublic
  interface DateServer extends Remote public
  Date getDate() throws RemoteException

interface Remote is just an empty marker
interface, like Cloneable and Serializable
Every class that you pass into or return from a
Remote object must implement java.io.Serializable.
22
RMI Example (2)
Client

• Client uses the remote service.

• import java.rmi.import java.util.Datepublic
  class DateClient public static void
  main(String args)
  throws Exception System.setSecurityManage
  r(new RMISecurityManager()) String what
  rmi//www.foo.com1099/MyDateServer
  DateServer server (DateServer)
  Naming.lookup(what) Date when
  server.getDate() System.out.println(time at
  server when)

• As we are downloading code from some server, the
  client needs some security policy.
• Specify a policy file (text-file, not XML) to
  grant permissions.

23
RMI Example (3)
Server

• Server implements the service.

• import java.rmi.import java.rmi.serverimport
  java.util.Datepublic class DateServerImpl
  extends UniCastRemoteObject
  implements DateServer
• public DateServerImpl() throws RemoteException
  
• public Date getDate()throws RemoteException
  return new Date() ...

Holds the extra capabilities for this object that
clients can create remotely.
All remote methods must be able to throw a
RemoteException.
24
RMI Example (4)
Server

• Server in the method main, the remote object is
  created and bound to the registry.

• public class DateServerImpl (cont.) ...
• public static void main(String args) throws
  Exception System.out.println(Attempting to
  bind server...) DateServerImpl server new
  DateServerImpl() Naming.bind(MyDateServer,
  server) System.out.println(Server bound
  succesfully)

Although the program reaches the end of the
method main, it does not terminate because the
act of binding starts a new thread running in
this process.
25
RMI - registry

• public class java.rmi.Naming
• public static void bind(String name, Remote
  obj)
• public static String list(String name)
• public static void unbind(Sting name)
• public static void rebind(String name,
  Remote obj)
• public static Remote lookup(String name)

//hostport/name
All these methods can throw numerous
RemoteExceptions.
26
RMI implementation (1)

• Client calls a local dummy routine which
  represents the one it wants to call remotely a
  stub.
• The stub is responsible for getting the incoming
  arguments and transmitting them over to its buddy
  on the server
• opens a socket
• serializes the objects (marshals)
• passes the data across
• Server after receiving the data, the buddy
  routine (skeleton) is called, which
• unmarshals the data and calls the real server
  method
• The procedure is then reversed to communicate the
  result back to the method on the client machine.

Under the hood ObjectInput- and
ObjectOutput-streams over a TCP/IP socket
connection.
27
RMI implementation (2)

• Stub en Skeleton

Client (JVM 1)
Server (JVM 2)
Remote
RemoteObject
method()
method()
Internet
Stub
Skeleton
28
RMI Example (5)
rmic

• Use Javas RMI compiler (rmic) to create class
  files for the stub and skeleton.
• rmic DateServerImpl
• creates DateServerImpl_stub.class
• should be stored at the client and server side
• could be send to the client after calling
  Naming.lookup()
• creates DateServerImpl_skel.class
• will stay at the server side.

skeleton not longer needed in Java 1.2.
rmic generates stubs for all methods declared in
the class Remotes interface
At client-side all client specific .class
files .class file of the interface file .class
file of the stub
At server-side all server specific .class
files .class file of the interface file .class
file of the stub and skeleton
29
RMI Example (6)
running

• Running the example
• start the RMI registry (on same machine as
  server!)
• rmiregistry
• start the server
• java DateServerImpl
• debugging the Serverjava Djava.rmi.server.logCa
  llstrue DateServerImpl
• start client
• java DateClient ltaddress of servergt

Now all RMI calls it receives will be printed.
You can also create and run a registry thread
from within the server java.rmi.registry.LocateRe
gistry.createRegistry(1099)
30
RMI Summary

• Define the remote interface (the service to be
  provided).
• Implement the remote interface (the server).
• Generate stub and skeleton classes using rmic.
• Write a client that locates the server in the
  naming registry and then calls remote methods.
• Start the naming registry using
  rmiregistry.Alternatively, the server can start
  the registry.
• Start the server (will not terminate).
• Run the client.

31
Further Reading
32
Promela models Java (1)

• Translation of Promela models to Java code seems
  straightforward

33
Promela models Java (2)

• Unfortunately, there are several incompatible
  features between Promela and Java.
• non-determism in Promela how to deal with this
  in Java?
• global memory in distributed environment?
• statement-granularity in Promela is more coarse
• assignment in Promela is atomic, but it is not in
  Java.
• There are no translators from Promela to Java.
• Refinement/translation is still a human, creative
  activity.
• Use the final, correct Promela model as the
  skeleton for the Java application.
• The translation from Java to Promela seems more
  feasible and successful.

34
JCSP (1)

• Promela is based on Hoares process algebra CSP.
• There are (at least) two libraries that offer
  CSP-constructs on the Java-object level.
• Communicating Threads for Java (CTJ) Gerald
  Hilderinkhttp//www.ce.utwente.nl/javapp/
• JCSP Peter Welchhttp//www.cs.ukc.ac.uk/project
  s/ofa/jcsp/
• Using either of these libraries could have
  advantages
• CSP (and its transputer language occam) have a
  large user base people know how to write correct
  CSP models.
• translation from/to Promela should be easier

35
JCSP (2)

• CSP (and occam)
• prefix x P
• recursion P a P
• choice P Q
• parallel operator P Q
• channels
• A JCSP process
• A process is an object of a class implementing
  the interface CSProcess.
• The behaviour of the process is determined by the
  body of its method run.

interface CSProcess public void run()
36
JCSP (3)

• Channels are accessed via two interfaces

interface ChannelInput public Object
read() interface ChannelOutput public
void write(Object obj)

• Some other evident JCSP constructs
• The Parallel class provides the CSP parallel
  operator.
• The Alternative class provides the CSP choice.
• CSTimer provides timeout guards for Alternatives.

37
JCSP (4)

• With these basic constructs, new composite
  processes can be constructed.

public class SuccInt implements CSProcess
private final ChannelInputInt in private
final ChannelOutputInt out public SuccInt
(ChannelInputInt in,
ChannelOutputInt out) this.in in
this.out out public void run()
while (true) int n
in.read() out.write(n 1)

SuccInt is a simple successor process that adds
one to the integer on the input channel.
38
Modern Model Checking

• No special modelling language, but program (in
  Java, C/C) language as input.
• Automatic extraction of a finite state model
  suitable for classic a model checker
• abstraction techniques
• static analysis techniques
• Some examples
• JPF (Java ? SPIN, JPF v2 to special purpose
  MC)http//ase.arc.nasa.gov/visser/jpf/
• Bandera (Java ? SPIN, SMV)www.cis.ksu.edu/bander
  a/
• FeaVer (C ? special version of SPIN, now
  publicly available)http//cm.bell-labs.com/cm/cs/
  what/feaver/index.html

39
Bandera
www.cis.ksu.edu/bandera/
BSL Based onProperty Patterns
Trans-lators
40
Threads in Java

• Summary of P2
• synchronized, wait, notify(All)
• monitors Java objects in which data and
  synchronized methods are encapsulated
• RMI
• Ben-Ari p. 94 rendezvous implements a remote
  procedure call
• Thread-safety assignment to variables that are
  32 bits or smaller is thread-safe.
• Problems with synchronized
• No timeout
• Some thread has to wait an unreasonable amount of
  time to acquire a lock on an object
• Object-level granularity of synchronized is too
  coarse for some situations there is only one
  monitor per object.