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
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
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
9.Whiteboard ExampleWhiteboard Example
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
10.Whiteboard ExampleWhiteboard Example
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
11.Whiteboard ExampleWhiteboard Example
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
13.Whiteboard ExampleWhiteboard Example
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
14.Whiteboard ExampleWhiteboard Example
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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
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
26.The Enforce Action ModuleThe Enforce Action Module
Locked Resources
SetPosition(...,...)
Is impossible if not locked
Thus:first Lockthen SetPosition
27.The Enforce Action ModuleThe Enforce Action Module
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
28.The Enforce Action ModuleThe Enforce Action Module
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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
ConcurrencyAdaptor
30.The Liveness ModuleThe Liveness Module
Ensures no starvation of the underlying component
Rewards & Reinforcement Learning
31.The Liveness ModuleThe Liveness Module
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!!))
32.The Liveness ModuleThe Liveness Module
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
33.The Liveness ModuleThe Liveness Module
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
34.The Liveness ModuleThe Liveness Module
(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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
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
37.The Concurrency ModuleThe Concurrency Module
Controlled Resources Managed Resources
38.The Concurrency ModuleThe Concurrency Module
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
ComponentBased System
Commonality/Variability Analysis
Petri-nets
Reinforcement Learning
Liveness Module
Logic Programming
Enforce Action Module
InventedAlgorithms
Concurrency Module
InventedRepresentations
Domain Specific Documentation
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