Distributed Software Systems

1

Distributed

Software Systems

Lecture 8Process-centric Computation

João Pedro Sousa

SWE 622

George Mason University

SWE 622 – Distributed Software Systems © Sousa, 2009

these few lectures:

different perspectives

on distributed computing:

access to services

communicating processes

data sharing

Lecture 8 – Process-centric Computation – 2

2


outline

understanding concurrency

modeling concurrent systems

FSP

predictability and consistency

synchronization

monitors



but same modeling & reasoning apply

c2

c1

c3

distributed

components (OS processes)threaded component

time

c1c2

c3

time

t1t2

t3

simultaneous processing interleaving

c1

t1

descdata code

desc

stackt3

desc

stack…

concurrent computations (aka events)

may occur in any order, unless explicit

steps are taken to synchronize them


3


aside

understanding threadswhy threads anyway?

separation of concerns:different activities in different threads

one thread remains responsive (e.g. user input)even if others are busy or blocked (e.g. waiting for messages)

support requests of multiple clients

using threads for replicated computation

pool: assign a thread when a request comes inmore efficient, harder to manage

factory: create a thread when a request comes ineasier to manage, less efficient

threads are supported by a library/VM, not the OS

making a process-blocking OS call blocks all threads

calling exit(i) in one thread terminates the process



the concurrent execution of two components/threads

generates all possible combinations of behavior

think of two components P and Q as state machines

if P has n states and j transitions

and Q has m states and k transitions,

the concurrent execution

has n*m states and j*k transitions

as the number of components grow

in a distributed system, this leads to

combinatorial explosion


4


models of concurrent processesplay a key role in getting distributed systems right

hard way:very hard to get right

for any but toy systems

requirements

c2

c1

c3 distributed system

model of

concurrentprocesses

automatic checking

well-known techniques

or:

henceforth, we call process to the model of a OS process/thread



models of concurrency

using Finite State Processes (FSP)

covered in (book)

Concurrency: State Models and Java Programming

J. Magee and J. Kramer. Wiley, 2006

has an associated tool

Labeled Transition State Analyzer (LTSA)

acknowledgement: much of the following material

is adapted from Magee and Kramer’s web site

http://www-dse.doc.ic.ac.uk/concurrency/


5


two forms to describe a process

FSP: textual notation to describe processes

LTS: Labeled Transition Systems (graphical form)

process defines the execution

of a finite state machine

(x-> P) describes a process that initially

engages in the action x and then behaves

exactly as described by Pon

off

0 1

example: SWITCH = OFF,

OFF = (on -> ON),

ON = (off-> OFF).



LTSA generates graphical view

& executes the process

supports editing and parsing of FSP specs

the LTSA animator can be used to produce a trace

ticked actions are eligible for selection

in the LTS, the current state is highlighted in red

on

off

0 1


6


syntaxof textual form

I66 = OFF,

OFF = (key -> IDLE),

IDLE = (gas -> MOVING),

MOVING = (brake -> CRASHED),

CRASHED = END.local processes (states)

all caps

parenthesized

separated by commas

actions

lower case

there exist two predefined processes that allow no further action

STOP – failed termination

END – successful termination

no need to name every state in the textual representation:

I66 = (key -> gas -> brake -> END).



quizwhich of these are syntactically correct?

# Process Definition Answer

1 Boring = Stop.

2 BORING = STOP,

3 BORING = (STOP).

4 PERSON = birth -> death -> END.

5 PERSON = (Birth -> Death -> END).

6 PERSON = (birth -> (death -> END)).

7 PERSON = ((birth -> death -> END)).

8 PersoN = (bIRTh -> dEATh -> END).

9 PERSON = (birth -> birth -> NEXT).


7


two types of choice

Deterministic Choice:

HUMAN = (

exercise -> healthy -> HUMAN

| study_only -> weak -> HUMAN ).

P = (x -> Q | y -> R) initially engages in either of the actions x or y;

subsequent behavior is described by

Q if the first action was x,

and R if the first action was y

Non-Deterministic Choice:

HUMAN = (

study -> wealthy -> END

| study -> poor -> END).



non-deterministic choice can be used to

model uncertainty (e.g., possible failures)

P = (x -> Q | x -> F) engages in x and

then behaves as either Q or F

example: tossing a coin

COIN = (toss->HEADS|toss->TAILS),

HEADS= (heads->COIN),

TAILS= (tails->COIN).

toss

toss

heads

tails

0 1 2

possible traces?


8


actions can be indexedindexes are always finite

same as

BUFF = (in[0]->out[0]->BUFF

|in[1]->out[1]->BUFF



).

example: a buffer with a single slot that

stores values in the range 0 to 3

BUFF = (in[i:0..3]->out[i]-> BUFF).



processes also can be indexed

const N = 3

range R = 0..N

STORE = BUF[0],

BUF[val:R] = (read[val] -> BUF[val]

| write[i:R] -> BUF[i] ).

STORE

{read, write}[0]

write[1]

write[2]

write[3]

write[0]

write[1]

write[2]

{read, write}[3]

write[0]

write[1]

{read, write}[2]

write[3]

write[0]

{read, write}[1]

write[2]

write[3]

0 1 2 3


9


can specify that an action may be taken

only when a certain condition is satisfied

example: up and down counter

COUNT (N=3) = COUNT[0],

COUNT[i:0..N] = ( when (i<N) inc -> COUNT[i+1]

| when (i>0) dec -> COUNT[i-1] ).

inc inc

dec

inc

dec dec

0 1 2 3

P = (when B x -> Q | y -> R)

if B is true then both x and y may be chosen

if B is false then x cannot be chosen



the concurrent execution of two processes

generates all possible combinations of traces

ITCH = (scratch->END).

CONVERSE = (think->talk->END).

||CONVERSE_ITCH = (ITCH || CONVERSE).

(0,0) (0,1) (0,2) (1,2) (1,1) (1,0)

from CONVERSEfrom ITCH 2 x 3 states

CONVERSE_ITCH

scratch

think

scratch

talk scratch

talk think

0 1 2 3 4 5


10


concurrent processes

synchronize on shared events(events that are in the alphabet of both processes)

LTS? Traces? Number of states?

MAKER = (make->ready->MAKER).

USER = (ready->use->USER).

||MAKER_USER = (MAKER || USER).

[Magee & Kramer 06] pp 391

P –a–> P’ a∉αQ

P||Q –a–> P’||Q

Q –a–> Q’ a∉αP

P||Q –a–> P||Q’

P –a–> P’, Q–a–>Q’ a ≠ τ

P||Q –a–> P’||Q’




synchronize on shared events





11



synchronize on shared events




MAKER_USER

make ready make

use use

0 1 2 3



concurrent behavior quickly gets complex,

automated tools lend valuable help

MAKE_A = (makeA->ready->used->MAKE_A).

MAKE_B = (makeB->ready->used->MAKE_B).

ASSEMBLE = (ready->assemble->used->ASSEMBLE).

||MAKE_AB_FIRST = (MAKE_A||MAKE_B).

||FACTORY1 = (MAKE_AB_FIRST || ASSEMBLE).

||ASSEMBLE_A_FIRST = (MAKE_A||ASSEMBLE).

||FACTORY2 = (ASSEMBLE_A_FIRST||MAKE_B).

do ||FACTORY1 and ||FACTORY2

have the same behavior?


12

take 5

SWE 622 – Distributed Software Systems © Sousa, 2009 Lecture 8 – Process-centric Computation – 23


outline

understanding concurrency

modeling concurrent systems

FSP

predictability and consistency

synchronization

monitors


13


concurrency challenges the

predictability of effects

P Q

P||Q

x=0;

x=x+2;

x=3;

x=x*2;

a.

b.

P=(a->b->END).

c.

d.

Q=(c->d->END).

how many possible values for x?



unpredictability is a problem for any system

with concurrent components sharing data

blackboard architectures

single data repository (blackboard)

all components read/write on blackboard

client-server with central database

multiple clients may access same DB records

c2c1 c3

bb

c2c1 c3

S


14


distribution challenges the

consistency of observed values

distribution

network propagation delays

different clocks

causes inconsistency

given one trace of events, different components

may see those events in a different order

c2c1

write 2write 1

write 1write 2



concurrency

causes unpredictability

cannot tell which trace will occur

distribution

network propagation delays

different clocks

causes inconsistency

given one trace of events, different components

may see those events in a different order


15


synchronization techniques address both

predictability and ordering consistency

programmers need to use

explicit synchronization techniques anyway,because of unpredictability (due to concurrency)

explicit synchronization

relieves the middleware/OS from

having to assure ordering consistency



monitorsare used for explicit synchronization

monitors are used for:

synchronize (wait for) specific conditions

control access to shared data

mutual exclusion on critical sections

monitors

guaranty that only one process

operates on the monitor at one time

support a queue of processes that are waiting for

the shared resource, or

some condition to be true


16


example: the parking lot[Magee & Kramer]

A controller only permits cars to enter

when the parking is not full,

and does not permit cars to leave

when there are no cars in the parking lot.



example: the parking lot

start by identifying structure and events

events or actions of interest?

arrival and departure

identify processes

arrivals, departures and CarPark control

define structure and interactions

ARRIVALS CARPARK

CONTROLDEPARTURESarrive depart

CarPark


17



model the processes in FSP

ARRIVALS = (arrive -> ARRIVALS).

DEPARTURES = (depart -> DEPARTURES).

||CARPARK = ( ARRIVALS || DEPARTURES

|| ).




model the processes in FSP

ARRIVALS = (arrive -> ARRIVALS).

DEPARTURES = (depart -> DEPARTURES).

CARPARKCONTROL(N=4) =

SPACES[N],

SPACES[i:0..N] = (when(i>0) arrive -> SPACES[i-1]

|when(i<N) depart -> SPACES[i+1]).

||CARPARK = ( ARRIVALS || DEPARTURES

|| CARPARKCONTROL(4) ).


18


class Arrivals extends Thread {

Arrivals(CarParkControl CPC) {

…}

void run() {

…

CPC.arrive();

…}

}


synchronization via shared object

class CarParkControl {

CarParkControl(…) {

…}

synchronized void arrive() {

…}

synchronized void depart() {

…}

}

class Departs extends Thread {

Departs(CarParkControl CPC) {

…}

void run() {

…

CPC.depart();

…}

}




translate the structure into Javaclass CarParkControl {

private int spaces;

private int capacity;

CarParkControl(int n)

{spaces = n; capacity = n;}


while !(spaces > 0) wait();

--spaces;

}


while !(spaces < capacity) wait();

++spaces;

}

}

FSP Java

SPACES[i:0..N] private int spaces, capacity

arrive arrive()

depart depart()

guards synchronization conditions

CARPARKCONTROL(N=4) = SPACES[N],




19



insert Java monitor primitives


private int spaces;






--spaces;

}



++spaces;

}

}

Java

provides a wait queue per object

guaranties only one thread at a

time obtains the lock




insert Java monitor methods


private int spaces;






--spaces;

}



++spaces;

}

}

java.lang.Object.wait()

blocks the executing thread

until notified by another thread

what’s missing?Lecture 8 – Process-centric Computation – 39

20



insert Java monitor methods


private int spaces;






--spaces;

notify();

}



++spaces;

notify();

}

}

java.lang.Object.notify()

unblocks a single thread

waiting on this object’s queue

the unblocked thread must get the lock




easier to understand structure and behavior in FSP


private int spaces;






--spaces;

notify();

}



++spaces;

notify();

}

}

CARPARKCONTROL(N=4) = SPACES[N],



||CARPARK = ( ARRIVALS || DEPARTURES || CARPARKCONTROL(4) ).

class Arrivals extends Thread {

Arrivals(CarParkControl CPC) {

…}

void run() {

…

CPC.arrive();

…}

}class Departs extends Thread {

Departs(CarParkControl CPC) {

…}

void run() {

…

CPC.depart();

…}

}


21


discussion

modeling simple synchronization

design a security application to check visitors,

two checks run in parallel:

face recognition against a DB of known offenders

chemical analysis looks for dangerous substances

visitor is only cleared after both finish



class Barrier {

Barrier(

}

class A extends Thread {

A(Barrier s1, s2) {…}

void run() {

dothis();

s1.ready();

dothat();

s2.ready(); …}

}

discussion

barriers support simple synchronization

class B extends Thread {

B(Barrier s1, s2) {…}

void run() {

sing();

s1.ready();

dance();

s2.ready(); …}

}

A = (dothis -> synch1 -> dothat -> synch2-> END).

B = (sing -> synch1 -> dance -> synch2 -> END).

||AB = ( A || B ).


Documents

Distributed Software Systems