Traversal techniques for concurrent systems

Traversal techniques for concurrent systems

Marc Solé & Enric Pastor

Departament of Computer Architecture

[email protected]

Introduction General objective: checking of safety

properties in concurrent systems.

Accomplished through Reachability Analisys.

Lot of work done for synchronous systems, but not for concurrent ones.

In this work: traversal methods for concurrent systems.

Concurrent systems particularities Transition relations (TR) partitioned in

smaller independent parts (events).

Each event is “fired” producing new states.

s0

s1 s2

s3

a

ab

bs0

s3

{a,b}

Synchronous Concurrent

Traditional Approach

Breadth First Search (BFS) does not take advantage of these particularities.

Our proposal: schedule the application of the events in a hybrid approach (BFS/DFS).

Overview Hypothesis

Speeding State Generation Causality Detection

Four traversal methods Token traverse Weighed token traverse Dynamic event-clustered traverse TR cluster-closure traverse

Results & Conclusions

Hypothesis “The faster, the better”.

Intuition: if you need less iterations to complete

the process, then the probabilities of encountering an intermediate “big” BDD diminish.

Obviously not true in all cases.

s0s0s0 s0

Speeding state generation Great results with a very simple

technique: chaining.

s1

a

s2

b

s3

b a

s1

a

s2

b

s3

b a

BFS BFS with chaining

s0 s0



s1

a

s2

b

s3

b a

s1

a

s2

b

s3

b a


s1



s0 s0

s1

a

s1

a

s2

b

s2

b

s3

b


a

s3

b a

Maximizing the chaining

The order of event firing has a significant impact on the performance.

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

BFS BFS with chaining BFS with chaining

{a,b,c,d,e,f,g}

{e,a,g,c,b,f,d}

{a,b,c,d,e,f,g}

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

BFS BFS with chaining BFS with chaining

{a,b,c,d,e,f,g}

{a,b,c,d,e,f,g}

{e,a,g,c,b,f,d}

Maximizing the chaining Information to obtain a good

scheduling Causality analisys between events.

Main idea: If I have fired event X, which events are fireable now.

Notation & Definitions The set of states in which an event is

“fireable” is called Firing Function (FF). In fact, characteristic function of the

set. Example:

FF(a)

s0

s1 s2

s3 s4 s5

s6 s7 s8

s9 s10 s11

s12

a

a

b

b b

c

c

e d

eb

e

a

a

db f

f

g

d

Causality Causality between TR a and TR b exists if:

You can fire a, but not b. You fire a. Now you can fire b.

FF(a) FF(b)

Causality Causality between TR a and TR b exists if:

You can fire a, but not b. You fire a. Now you can fire b.

FF(a) · !FF(b)

Causality

To

To = Firing a on FF(a)*!FF(b)

Causality between TR a and TR b exists if: You can fire a, but not b. You fire a. Now you can fire b.

aa

aFF(a) · !FF(b)

FF(a) · !FF(b)

Causality

To

FF(b)

If this set exists

[To · FF(b) ]

then event b potentially becomes fireable after event a

Causality between TR a and TR b exists if: You can fire a, but not b. You fire a. Now you can fire b.

Causality Checking the causality for each pair of

events, we can determine the causality relations between all the events in the system.

This information can be stored in different ways (i.e. matix).

For clarity we use a Petri-Net like model to represent these relations.

Petri Nets Structure to represent relationships

(synchronicity/concurrency) between components. Three components:

Places: potential state. Transitions: dynamic behaviour. Tokens: present state.

Causality Example: s0

s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c

Traversal methods

Token traverse Put one initial token in all fireable events.

Fire the event with highest number of tokens.

If firing does not generate any new state, then the token is “absorbed”.

When all the tokens have been absorbed, compute the new states generated by this iteration.

If no new, fixpoint reached, else restart.

Token traverse Example: s0

s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c


s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c

Same number of tokens in a and b :Chose at random which to fire


s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c

Same number of tokens in b and c :Chose at random which to fire


s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c

Worst case: c is firedNo new state produced,

token absorbed


s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

a b

c

Problems with Token Traverse Ineffective firings. As in the case of

event c in the previous example.

s0

s1 s2

s3

a

a

b

b

c

a b

c

Problems with Token Traverse

To solve this problem and produce a better scheduling we can try to relate: number of tokens in one place number of states in which this event

is fireable.

Weighed Token Traverse Every time an event is fired, for each

successor, we add a number of tokens equal to the number of states in which this successor is fireable.

s0

s1 s2

s3

a

a

b

b

c

a b

c

Weighed Token Traverse

In the former example, token from place a is now actually absorbed, as state s1 FF(c).

s0

s1 s2

s3

a

a

b

b

c

a b

c

Weighed Token Traverse

This solves ineffective firing problem, but increases BDD operations. For each firing we must perform k AND operations, being k the number of successors of an event.

Fortunately, in our benchmarks k is usually small (<4).

Weighed Token Traverse However this method does not

consider the fireable states produced by concurrent events.

s0

s1 s2

s3

a

a

b

b

c

a b

c2 states but only 1 token

Best fireable event? Both previous methods try to find out

which is the best fireable event at every moment.

A possible heuristic: fire the event that will produce more states.

Events are usually bijective functions, so the problem is equivalent to find out which event has more states in which it is fireable.

Best fireable event? For each event, keep track of the

number of states in which it is fireable. Every event has its own from set, that

is the smaller BDD from the following: The global from or, The set formed only by its fireable states.

Dynamic event-clustered traverse


s0

s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

Event a

Event b

Event c

s0

s0

Ø


s0

s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

Event a

Event b

Event c

s0

Ø

Ø

s1


s0

s1 s2

s3

s4

s5 s6

s7

a

a

b

b

c

a

a

b

b

Event a

Event b

Event c

Ø

Ø

Øs2

s3

There is a limit?

If we had the perfect algorithm that selected always the best fireable event, would it be possible to go faster than that?

There is a limit? TRs may be combined. We can compute the transitive

closure of these new TRs.

a b

Original Combined Closure

a ba b

ab

TR cluster-closure traverse Main idea: keep combining and

closuring TRs until we reach a threshold limit (BDD size).

Advantages: Reduces considerably the number of

steps needed to complete the traversal. This method is orthogonal with the

previous ones

TR cluster-closure traverse Drawbacks:

Setup time may be not negligeable if the TRs to combine are not selected carefully.

New TRs are bigger and usually have more variables.

Results RGD-arbiter [1], 63 vars, 47 events, reachable set has

5.49046e+13 states.

BFSBFS chain

TOKWTOKDEC

TRCC man

Steps #Events Peak Time (s)>38 >1786 >1755 >14400

24 1175 1755 14768 1430 20 30

10 1280 20 26N/A 1334 50 82

10 55 63 45

[1] M. R. Greenstreet et al, Proceedings of 5th Int. Symp. on ARACS, pp. 173-185, IEEE, Apr. 1999

Results STARI(16) [2], 100 vars, 100 events, reachable set has

4.21776e+22 states.

BFSBFS chain

TOKWTOKDEC

TRCC man

Steps #Events Peak Time (s)>329 >33000 - >8800

127 12800 440 2435>34 N/A >1590 >10800

67 10555 698 8890N/A 8135 572 7997

48 5550 852 138

[2] M. R. Greenstreet, STARI: A TECHNIQUE for High-Bandwidth COMMUNICATION, PhD. Thesis, 1993

Conclusions Scheduling of individual application of

TRs can improve the traversal process.

Reducing the number of iterations, helps avoiding the BDD blowups.

Four scheduling heuristics introduced.

Each one has its own strengths and weaknesses, depending on the class of the system.

Traversal techniques for concurrent systems

Documents

Transcript of Traversal techniques for concurrent systems