Docstoc

Creation of an Intelligent Concurrency Adaptor in order to mediate

Document Sample
Creation of an Intelligent Concurrency Adaptor in order to mediate Powered By Docstoc
					                                                         1.




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



                          e-mail: werner.van.belle@vub.ac.be
                       Programming Technology Lab (PROG)
                             Departement Informatica (DINF)
                             Vrije Universiteit Brussel (VUB)
                                                      2.
Open 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 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.
Approach
 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.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning
                                                                                Classifier
                                                                                Systems
      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module                                                       Scheme



                              Concurrency                        GA's/GP's
             Petri-nets
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                                                             6.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning
                                                                                Classifier
                                                                                Systems
      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module                                                       Scheme



                              Concurrency                        GA's/GP's
             Petri-nets
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                            7.
Case Study


 Whiteboard
 Implicit Agreement
   Different actors can
   set positions on board
   Actors should not
   cross each others
   boundaries
                                                      8.
Whiteboard Example
 Different Concurrent Autonomous Actors

 Modelled in SEESCOA Component System
 ●   Whiteboard & Actors are autonomous   Moving
     components                           Line
 ●   Event Based communication
                                          Moving
                                          Dot

            Whiteboard
                                          Floodfill
                                          Actor
                                                              9.
Whiteboard Example
 Unmanaged Concurrency leads to corruption
                     Red asks 'free ?'
                     Yellow asks 'free ?'
                     Whiteboard answers 'yes' to red
                     Whiteboard 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 Example
 Different Concurrency Strategies possible

     Client Actor requires to lock squares
       out 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 Example
 Different Concurrency Strategies possible

         Binary Semaphore
         Counting Semaphores
         Square Locks
         Field Locks
         Two layered locking strategy
         ...




                ... which set of conflicts will we investigate ?
                                                                           12.
Variabilities
  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 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                   Moving
    modified as necessary                                 Line
    Allows for easy adaptor deployment

                                                          Moving
                                                          Dot

 Whiteboard                    Adaptor
                                                          Floodfill
                                                          Actor
                                                                    14.
Whiteboard Example
  Insertion of Adaptor

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


                                                        Moving
                                                        Dot

 Whiteboard                     Adaptor
                                                        Floodfill
                                                        Actor
                                                                                       15.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                              16.
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...

         ... impossible without extra formal documentation


  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
                                                                18.
Petri-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 (8.2)
                                                                                       20.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                  21.
The Adaptor
  Adaptor subdivided in modules
    Liveness module (avoids starvation)
    Concurrency module (avoids race conditions)
    Enforce action module (avoids conflicts)
                                                                          22.
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 ?
  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.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                                25.
The 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 Module

                         SetPosition(...,...)


                       Is impossible if not locked

                       Thus:
                       first Lock
                       then SetPosition




    Locked Resources
                                                                               27.
The 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 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.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                      30.
The Liveness Module
  Ensures no starvation of the underlying component
  Rewards & Reinforcement Learning
                                                                   31.
The Liveness Module
  A mix of symbolic operation and numerical learning
    Symbolic operation                  (dynamic-0
                                          (in lock-out?? [TMP2 11])
      Too many possible actions           (in lock_true?!)
                                          (out lock_true!!))
      Swap arguments,                   (dynamic-1
      modify arguments,                   (in unlock-out?? [3 TMP2])
                                          (in return_unlock?!)
      fill in blanks...                   (out return_unlock!!))
      Action are described in a         (dynamic-9
                                          (in unlock-out?? [TMP2 TMP1])
      certain representation and          (in return_unlock?!)
      created randomly                    (out return_unlock!!))
                                        (dynamic-63
      Representation & algorithm          (in lock-out?? [TMP1 12])
      are correct bias.                   (in lock_true?!)
                                          (out lock_true!!))
      Tested by a genetic algorithm !   (dynamic-111
                                          (in lock-out?? [TMP1 TMP2])
                                          (in lock_true?!)
                                          (out lock_true!!))
                                                               32.
The Liveness Module
  A mix of symbolic operation and numerical learning
    Numerical learning
      Which actions to favour ? The number of possible actions is
      very large
      The liveness module needs to keep track of which actions
      are usefull and which aren't
      Reinforcement learning (Q learning mapped to problem)
      Underlying component assigns rewards for actions (Markov)
      Every transition in the Petri-net keeps a Q-value
      This mapping makes use of the structural information
      present in the net
      This mapping reduces memory requirements
                                                                      33.
The 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 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.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                                36.
The 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 Module




   Controlled Resources   Managed Resources
                                                                         38.
The 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 squares
    Joinactor
 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 squares
    Joinactor is not managed
 Based on this information actions can be sequentialised
                                                                                       39.
Overview
                                                                     Invented
Invented                      Logic                                  Representations
Algorithms                Programming          Reinforcement
                                               Learning



      Concurrency         Enforce Action
      Module                                   Liveness Module
                          Module



             Petri-nets       Concurrency
                              Adaptor

                             Domain Specific
Component                    Documentation
Based System
                               Preliminary
                               Tests                     Commonality/
                                                         Variability Analysis
                                Modelling
                                Case

                                 The Case
                                                                   40.
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)
                                                                        42.
Contributions
  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)
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)
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.
Limitations
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 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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:4/23/2011
language:English
pages:46