zero-safe net models for transactions in linda

Post on 25-Feb-2016

46 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

ConCoord: International Workshop on Concurrency and Coordination Lipari Island, Italy, 6-8 July 2001. Zero-safe net models for transactions in Linda. Roberto Bruni Ugo Montanari University of Pisa. Transaction of the Talk. two design postulates. - PowerPoint PPT Presentation

TRANSCRIPT

Zero-safe net models for transactions in Linda

Roberto BruniUgo Montanari

University of Pisa

ConCoord: International Workshop on Concurrency and CoordinationLipari Island, Italy, 6-8 July 2001

Transaction of the Talktwo design postulates

Petri, Linda, JavaSpaces, join, cham, ambient, , spi …

transactions are useful

in many different flavours

unifying transactions

in a concurrent scenario, via uniform syntax

zero-safe approach

extended, inhibitor arcs, TraLinda concurrent

semantics of Linda

net flavours

examples

conclusion and future work

Common Design Postulates

I. STATES ARE MULTISETS(e.g. of resources, agents, functions, rules,…)facilitates definition of reductions semantics(components can react when “close”)

II. ELEMENTARY ACTIONS CAN ATOMICALLY FETCH/RELEASE SEVERAL COMPONENTS

(synchronized at the event level)concurrent computations arise by state distribution

A Saucerful of Processes

A Saucerful of Processes

A Saucerful of Processes

A Saucerful of Processes

A Saucerful of Processes

On TransactionsI + II = Petri nets, Linda, JavaSpaces, cham, join,

ambient, , spiIII. EXPRESS TRANSACTIONS

(e.g. group events into work units that either completely succeed or have no effect)

important issue to provide reliable services, encoding, refinement/abstraction, …

transactions in a concurrent scenario (as opposed to a sequential or interleaving one)

Some Flavours of Transactions

EX. Transactions in databases (atomic updates, interest in serializability)schedule of primitive update operations must be

“equivalent” to a schedule of atomic updates

[A1:read x; A2:write x][B1:read x; B2:write x]

A1 A2 B1 B2 okB1 B2 A1 A2 okA1 B1 A2 B2 no

More FlavoursEX. Reliable multicast either all processes in a group receive a multicast

or none of them does

EX. Fault tolerant service(e.g. e-commerce: don’t pay if service is

not delivered and vice versa)

One More FlavourEX. Nested transactions

A

D

C

B(1)(2)

(3)

(1)

(2) (3)

(1) fails (2),(3) fails

(2) or (3) fails (1) may still succeed

A Last FlavourEX. Design complex systems via refinement compositionality issuesactivities can vary in durationdistributed commitconsistency of local choicesmove freely between the abstract and the

refined view of systems

Abstraction/Refinement I

Abstraction/Refinement II

Unifying TransactionsAd hoc transaction mechanisms are integrated

in many languages (e.g. BizTalk Orchestration and JavaSpaces)Can we find a uniform way to handle point III

in existing frameworks?Two main issues must be considered:

(i) theoretical characterization of transactions(ii) definition of a distributed interpreter

The convenient way: Uniform syntax for III (like I and II) Visual formalism

Net FlavoursThe simpler model: Petri nets

Progressive enrichments to encompass limitations of the basic paradigm

(see e.g. [Asperti Busi] [Buscemi Sassone])

2

3 2

ba

c d

Coloured (or High Level)

x |y|

1 5 “s”

6

x y

y.y x+3

“ss”

4

ba

c d

structured data as tokens

Reconfigurablec d

x y

y x

ba

x y

ac

c cc c

postsets may depend on read values:

network reconfigurability vs. static connectivity

Dynamic c d

x y

ba ac

a firing can modify the “control”, increasing the set of transitions (very similar to join)

N(x,y)

X

Read Arcsba

c d

multiple concurrent accesses in “reading”

Inhibitor Arcsb

a

c

dincrease expressiveness (reachability is no longer decidable)

t0

t1

t2

e

And Also…with timewith prioritieswith probabilities…ZERO-SAFE

n-safe place: contain at most n tokens in any reachable marking

0-safe place: cannot contain tokens!

but can contain tokens during the execution of a transaction

Zero-Safe NetsAlmost like Petri nets, but…stable placesordinary placeszero places empty in stable markings, tokens

produced must be fetched before commit transactions concurrent execution whose

intermediate states are non-stablegraphically

stable tokens produced during a transaction cannot be reused in the same transaction

ba

c d

z

BehaviourOrdinary nets:

S places, S markings, T transitions t : uv

Zero-Safe netsS stable places, Z zero places, (SZ) S

Z T transitions t : (u,x)(v,y)

uS

u ut : uvT

u vu v u’ v’uu’ vv’

ux vy(u,x) (v,y)

(u,0) (v,0) (uu’,x) (vv’,y’)

(u,x) (v,y)

u v

(u’,y) (v’,y’)

Abstract NetZN zero-safe net, we look for an ordinary Petri net N s.t.

1) SN = SZN

2) N = ZN Informally, the transitions of N are the (concurrent) proofs of transaction steps in ZN: t : uv N u v ZN Not all proofs are necessary, but only an essential subseta) considered up to permutation of concurrent eventsb) cannot be decomposed into shorter proofsResultsi. transactions via free constructionii. abstract net via universal construction (optimal)iii. distributed interpreter based on “net unfolding”

Example: From Free Choice to Non-Deadlocking I

Example: From Free Choice to Non-Deadlocking II

Example: From Free Choice to Non-Deadlocking III

Example: Multicasting I

2

b

a

c

z

new send

receive copyreset

Example: Multicasting II

b

a

c

new

1-to-n1-to-1 1-to-2reset … …

2

2

3

3

n+1

n+1

Zero-Safe and Read ArcsIt is forbidden to first read and then consume a

stable token inside the same transaction!

read token, cannot be fetched

Example: Multicasting III

b

a

c

z

new open

receive

close

reset

Zero-Safe and Inhibitor Arcs

It is forbidden to 0-test zero places!

The net is ambiguous! At the abstract level: Two independent activities or not?

Transactions in Linda

Linda-like process calculusP 0 | M | .P | ?P:P | P+P | PPM a out(a) | rd(a) | in(a) | !in(a) rdp(a) | inp(a)[Busi Gorrieri Zavattaro]: truly concurrent

semantics via nets (employing read and inhibitor arcs)

Net Semantics for Linda

rdp(a)?P:Q

aN(P) N(Q)

Example N(rdp(a)?P:Q)

Ordered vs. Unordered

out(a).P

a

N(P)

Example N(out(a).P)

a

N(P)

out(a).P

a

emission

rendering

emission +rendering

Zero-Safe ApproachBuilt on the net semantics of Linda termslow-level messages vs. high-level messages(zero-safe) (stable)

Typing relation a: {L,H}Atomic prefixing _P

We call TraLinda the resulting process algebra

Net Semantics for TraLinda

Straightforward adaptation of the exisiting one for Linda (stable guards only)

in(a)_out(b).P

a

N(P)

Example N(in(a)_out(b).P)a:L b:H

{out(b).P}

b

More TraLinda Examplesout(a).P in(a).Q

asynchronous communication if a:Hsynchronized communication if a:L

in(a1)_out(z)in(a2)_out(z)in(z)_in(z)_Pai:H z:L atomically fetches a1 and a2

Ordered vs. Unordered IIExample N(out(a).P)

a

N(P)

out(a).P

a

CommitZS approach = a common language for

distributed transactionsHere extended to handle inhibitor arcs

and applied to concurrent modeling of Linda with transactions

Comparison with the previous talkExtension to reconfigurable and dynamic

nets (i.e. join-calculus)two kinds of names (zero and stable)nested transactions (flat vs. hierarchical view)typing discipline and distributed interpreter

top related