1. creation of an intelligent concurrency adaptor in order to mediate the differences between...

1.

Creation of an Intelligent Concurrency Creation of an Intelligent Concurrency Adaptor in order to mediate the Adaptor in order to mediate the Differences between Conflicting Differences between Conflicting

Concurrency InterfacesConcurrency Interfaces

e-mail: [email protected] Technology Lab (PROG)

Departement Informatica (DINF)Vrije Universiteit Brussel (VUB)

2.Open Distributed SystemsOpen Distributed Systems

Examples

The internet

Peer to peer computational networks

Mobile embedded systems

Summary

Hostile environment

Uncontrollable upgrades

Volatile Interactions

Unknown communication partners

Results in Interface Conflicts

3.Thesis StatementThesis Statement

In open distributed systems adaptors between concurrency strategies are necessary,

We show that creating such an adaptor is possible

We do this empirically

4.ApproachApproach

Problem of conflicting interfaces is too big for one PhD

Started from a non-trivial case, expressed in an experimental model

Created a set of possible real-world conflicts

Tried to solve these conflicts automatically, with as less information as possible

Results in

A concurrency adaptor that solves the investigated conflicts automatically

A dissertation that can be used as a guideline for possible future adaptors

5.

The Case

Modelling Case

PreliminaryTests

Overview Overview

ComponentBased System

Commonality/Variability Analysis

Petri-nets GA's/GP's

ClassifierSystems

Reinforcement Learning

Liveness Module

Logic Programming

Enforce Action Module

InventedAlgorithms

Concurrency Module

InventedRepresentations

Scheme

Domain Specific Documentation

ConcurrencyAdaptor

6.

The Case

Modelling Case

PreliminaryTests

Overview Overview



Petri-nets GA's/GP's

ClassifierSystems


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module


Scheme


ConcurrencyAdaptor

7.Case StudyCase Study

Whiteboard

Implicit Agreement

Different actors canset positions on board

Actors should not cross each others boundaries

8.Whiteboard ExampleWhiteboard Example

Different Concurrent Autonomous Actors

WhiteboardWhiteboard

Moving Dot

Moving Dot

Moving Line

Moving Line

FloodfillActor

FloodfillActor

Modelled in SEESCOA Component System

● Whiteboard & Actors are autonomous components

● Event Based communication


Unmanaged Concurrency leads to corruption

Red asks 'free ?'Yellow asks 'free ?'Whiteboard answers 'yes' to redWhiteboard answers 'yes' to yellow

Red sets position Yellow sets the same position

Red asks 'free ?'Yellow asks 'free ?'Both continue

... requires a concurrency strategy


Different Concurrency Strategies possible

Client Actor requires to lock squaresout lock(x, y)in lock_true()in lock_false()

Server Actor provides locking columns

in lock(x)out lock_true()out lock_false()

... leads to conflicts


Different Concurrency Strategies possible

Binary SemaphoreCounting SemaphoresSquare LocksField LocksTwo layered locking strategy...

... which set of conflicts will we investigate ?

12.VariabilitiesVariabilities

To select a set of conflicts we identified 6 variabilities

Syntactical

Control Flow: E.g: waiting locks, non-waiting locks

Reentrancy: E.g: can we lock the same field twice ?

Resources: E.g: lock field/square/column/row...

Transition: E.g: can we go back to an older state ?

Layering: E.g: first lock server, then lock square, finally use it..

... leads to 22 interesting conflicts


Insertion of Adaptor

SEESCOA Component System = runtime system

All communication goes through the component system

System itself is reflective: creation, addressing and communication can be modified as necessary

Allows for easy adaptor deployment

WhiteboardWhiteboard AdaptorAdaptor

Moving Dot

Moving Dot

Moving Line

Moving Line

FloodfillActor

FloodfillActor


Insertion of Adaptor

WhiteboardWhiteboard AdaptorAdaptor

Moving Dot

Moving Dot

Moving Line

Moving Line

FloodfillActor

FloodfillActor

Mediates differences between components such that clients thinks they are talking to a 'normal' server & the server thinks it is talking to 'normal' clients.

15.

The Case

Modelling Case

PreliminaryTests

OverviewOverview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

16.Adaptor should ...Adaptor should ...

Avoid

Race-conditions

Conflicts

Starvation

Practical

be as automatic as possible

no repository of A x A adaptors

should work at runtime

... impossible without extra formal documentation

17.Matching the requirements...Matching the requirements...

Without API

Don't even know what the receiver can possibly understand

With syntactical API

Don't know which message can be sent when

Not sure that sending a message results in corruption

Need more semantic information

Petri-nets & Checkpoints

... impossible without extra formal documentation

18.Petri-netsPetri-nets

Allows for deduction of interesting properties

Deadlock-freedom

Homestate

Termination

Reachability

Colored Petri-nets contains structural information

Can specify which message can be sent/might arrive when

Is perfectly suited to specify concurrency strategies

Probably suited for describing other API's as well

Easy understandable because of intuitive graphical notation

Required/provided interface

19.Petri-nets: Counting Semaphore Petri-nets: Counting Semaphore (8.2)(8.2)

20.

The Case

Modelling Case

PreliminaryTests

OverviewOverview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

21.The AdaptorThe Adaptor

Adaptor subdivided in modules

Liveness module (avoids starvation)

Concurrency module (avoids race conditions)

Enforce action module (avoids conflicts)

22.Topology ?Topology ?

No conflict requirement

If a message is not understood by the server then we have a conflict.

Knowing ...

what a server understands how to make a server accept certain messages

Solves this problem but requires a reachability analysis -> server-side prolog module

23.Topology ?Topology ?

No race-conditions

Solving race conditions requires the ability to observe the behavior of all communication partners

Requires the adaptor to see all interaction -> centrally placed algorithm

Liveness Requirements

Necesarry feedback from underlying components: checkpoints

Modify behavior at runtime-> client-side reinforcement learning

24.

The Case

Modelling Case

PreliminaryTests

OverviewOverview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

25.The Enforce Action ModuleThe Enforce Action Module

Takes care of the no conflict requirement

Given a required marking and a current marking, this module decides how to bring the server in the required state


Locked Resources

SetPosition(...,...)

Is impossible if not locked

Thus:first Lockthen SetPosition


Requirement formalised as:

X is in conflict with Y if there is a functional transition that is only enabled in X or Y.

Given the two Petri-nets and the current markings the enforce-action module will 'force' the server to be in a certain state

Enforce actions on server side, 'just in time'

Investigate the necessary required 'enabled' transitions

Send synchronisation message

Execute transition


Assumptions

Server is under full control of the enforce action module

Server can always enable a required state again

Distinction between functional and synchronisation messages

Discussion

The reachability problem itself is in general NP complete

Prolog code is able to calculate a path immediatelly

All synchronisation strategies seem very simple

Certain synchronisation strategies require the possibility to bring the servers state back to an older state

29.

The Case

Modelling Case

PreliminaryTests

Overview Overview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

30.The Liveness ModuleThe Liveness Module

Ensures no starvation of the underlying component

Rewards & Reinforcement Learning


A mix of symbolic operation and numerical learning

Symbolic operation

Too many possible actionsSwap arguments,modify arguments,fill in blanks...Action are described in acertain representation andcreated randomlyRepresentation & algorithm are correct bias. Tested by a genetic algorithm !

(dynamic-0 (in lock-out?? [TMP2 11]) (in lock_true?!) (out lock_true!!))(dynamic-1 (in unlock-out?? [3 TMP2]) (in return_unlock?!) (out return_unlock!!))(dynamic-9 (in unlock-out?? [TMP2 TMP1]) (in return_unlock?!) (out return_unlock!!))(dynamic-63 (in lock-out?? [TMP1 12]) (in lock_true?!) (out lock_true!!))(dynamic-111 (in lock-out?? [TMP1 TMP2]) (in lock_true?!) (out lock_true!!))


A mix of symbolic operation and numerical learning

Numerical learning

Which actions to favour ? The number of possible actions is very largeThe liveness module needs to keep track of which actions are usefull and which aren'tReinforcement learning (Q learning mapped to problem)Underlying component assigns rewards for actions (Markov)Every transition in the Petri-net keeps a Q-valueThis mapping makes use of the structural information present in the netThis mapping reduces memory requirements


Experiments

Tested our approach on the clients of all concurrency conflicts

Learning rate = 0.1

Discount factor = 0.9

Discussion

Reinforcement learning is essential in deciding which randomly generated actions to keep !

Discount Factor: reward assigned when a complete line has been locked

Oscillation when no immediate relationship with synchronisation: non-markov


(dynamic-0 (12) (in lock-out?? [9 TMP1]) (in lock_true?!) (out lock_true!!))(dynamic-1 (3) (in unlock-out?? [TMP1 14]) (in return_unlock_true?!) (out return_unlock_true!!))(dynamic-10 (189) (in unlock-out?? [TMP1 TMP2]) (in return_unlock_true?!) (out return_unlock_true!!))(dynamic-13 (182) (in lock-out?? [TMP1 TMP2]) (in lock_true?!) (out lock_true!!))(dynamic-16 (2) (in unlock-out?? [TMP2 TMP1]) (in return_unlock_true?!) (out return_unlock_true!!))

35.

The Case

Modelling Case

PreliminaryTests

Overview Overview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

36.The Concurrency ModuleThe Concurrency Module

Ensures no race-conditions

Uses the different Petri-net markings to decide which actions to allow or queue.

Deduces a set of controlled resources

Deduces a set of managed resources


Controlled Resources Managed Resources


Deduces a set of controlled resources

A transition is under control of a client if it can be executed immediatelly or if its state can be modified directly or indirectly through using synchronisation messages.

The locked squaresJoinactor

Deduces a set of managed resources

A transition is managed if the client offers the possibility to the concurrency module to choose between different futures.

All squaresJoinactor is not managed

Based on this information actions can be sequentialised

39.

The Case

Modelling Case

PreliminaryTests

Overview Overview



Petri-nets


Liveness Module

Logic Programming


InventedAlgorithms

Concurrency Module



ConcurrencyAdaptor

40.Overall Results (I)Overall Results (I)

Positive Results

18 conflicts correctly mediated

1 conflict mediated by improving the 'requested behavior'

Possibility Tests

1 fails because of virtual resources

1 fails because checkpoints are assigned in a non-markov way

No Results

2 experiments were not performed because they were peer-to-peer concurrency problems

41.Overall Results (II)Overall Results (II)

Conflict Possible Liveness Concurrency Enforce ResultDeadlock Module Module Module

Simple Syntax Ok Ok Ok OkParameter Encoding Ok Ok Ok Ok

Simple Reentrancy Yes No Choice +Dead Ok OkAsync Reentrancy Ok Ok Ok Ok

Simple Control Flow Ok Ok Ok OkIdle Control Flow Non Markov N/A Ok Fail

Wait client/Non wait serv Yes No Choice +Dead Ok OkNested line serv, square client Ok Ok Ok Ok

Non-nest line serv, square client Ok Ok Ok OkSquare serv, field client Ok Ok Ok Ok

Layer serv, non-layer client Yes Ok +Dead Ok OkLayer client, non-layer serv Ok -Dead Ok Fail

Transition Ok State State OkNested transition Ok State State Ok

Layered transition Ok State State OkTransactional client Ok State State Ok

Empty Server Yes No Choice +Dead Ok OkUpscale Granularity Yes Ok +Dead Ok Ok

Downscale granularity Ok Ok Ok OkWait clients, non-wait serv Yes Ok Ok Ok Ok

Multi-multi conflict Ok N/A Ok N/AMulti-multi confilct 2 Ok N/A Ok N/A

42.ContributionsContributions

We explained

that components in an open system need a concurrency strategy

that concurrency conflicts are an essential problem in open systems -> hence open systems need concurrency adaptors

how Petri-nets can be used to describe component interfaces

how an intelligent concurrency adaptor can be constructed

how GA's can be used to verify the bias of a representation. This helps in choosing a correct representation

how an event based model allows for easily adaptor creation

First hand experience in solving interface-conflicts has lead to a set of guidelines.

43.Guidelines (I)Guidelines (I)

1 Explore the application domain

2 Identify necessary information

3 Correctly represent this information

Narrow down expressive power

Make this extra information useful

4 Explicitly state adaptor requirements

44.Guidelines (II)Guidelines (II)

5 Correctly represent the adaptor

Narrow down expressive power of adaptor

Introduce a correct bias with automatic representation validation (genetic algorithms)

6 Modularise the different requirements

5 Based on their input/output

6 Based on their solution

7 Plug & pray !

45.LimitationsLimitations

1 Relatively small problem (concurrency conflicts) in comparison to the bigger problem (interface conflicts)

2 Requires a correct working second link (functional behavior) between the different components.

3 Requires a clear separation between concurrency interfaces and functional interfaces.

4 The experimental component model is event based. Thread based interaction has not been investigated.

5 Only one example, a whiteboard case.

46.Future WorkFuture Work

Peer to Peer concurrency

Other learning approaches

Automatically learning an interface description

On-line vs off-line

Investigate how this work can be transposed to other domains

Large Object Oriented (Thread based) Applications

Investigate the possibility to redo this process in a semi-automatic way

1. creation of an intelligent concurrency adaptor in order to mediate the differences between...

Documents