DOCSLIB.ORG

Reactors: a Deterministic Model of Concurrent Computation for Reactive Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Reactors: a Deterministic Model of Concurrent Computation for Reactive Systems Reactors: A Deterministic Model of Concurrent Computation for Reactive Systems Marten Lohstroh Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2020-235 http://www2.eecs.berkeley.edu/Pubs/TechRpts/2020/EECS-2020-235.html December 21, 2020 Copyright © 2020, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Reactors: A Deterministic Model of Concurrent Computation for Reactive Systems by Hendrik Marten Frank Lohstroh A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Edward A. Lee, Chair Professor Gul A. Agha Professor Alberto L. Sangiovanni-Vincentelli Professor Sanjit A. Seshia Fall 2020 Reactors: A Deterministic Model of Concurrent Computation for Reactive Systems Copyright 2020 by Hendrik Marten Frank Lohstroh i Abstract Reactors: A Deterministic Model of Concurrent Computation for Reactive Systems by Hendrik Marten Frank Lohstroh Doctor of Philosophy in Computer Science University of California, Berkeley Professor Edward A. Lee, Chair Actors have become widespread in programming languages and programming frameworks focused on parallel and distributed computing. While actors provide a more disciplined model for concurrency than threads, their interactions, if not constrained, admit nondeter- minism. As a consequence, actor programs may exhibit unintended behaviors and are less amenable to rigorous testing. The same problem exists in other dominant concurrency mod- els, such as threads, shared-memory models, publish-subscribe systems, and service-oriented architectures. We propose \reactors," a new model of concurrent computation that combines synchronous- reactive principles with a sophisticated model of time to enable determinism while preserving much of the style and performance of actors. Reactors promote modularity and allow for dis- tributed execution. The relationship that reactors establish between events across timelines allows for: 1. the construction of programs that react predictably to unpredictable external events; 2. the formulation of deadlines that grant control over timing; and 3. the preservation of a deterministic distributed execution semantics under quantifiable assumptions. We bring the deterministic concurrency and time-based semantics of reactors to the world of mainstream programming languages through Lingua Franca (LF), a polyglot coordination language with support (so far) for C, C++, Python, and TypeScript. In LF, program logic is given in one or more of those target languages, enabling developers to use familiar languages and integrate extensive libraries and legacy code. The main contributions of this work consist of a formalization of reactors, the imple- mentation of an efficient runtime system for the execution of reactors, and the design and implementation of LF. i To Rusi and Luka. ii Contents Contents ii List of Algorithms iii List of Figuresv List of Code Listings vii List of Tables ix 1 Introduction1 1.1 Motivation..................................... 1 1.2 Background.................................... 4 1.3 Contributions................................... 11 1.4 Related Work................................... 12 1.5 Outline....................................... 17 2 Reactors 18 2.1 Ports, Hierarchy, and Actions .......................... 19 2.2 State Variables .................................. 20 2.3 Connections.................................... 20 2.4 Example: Drive-by-wire System......................... 21 2.5 Formalization................................... 23 2.6 Dependency Analysis............................... 40 2.7 Execution Algorithm............................... 44 2.8 Implementations ................................. 50 3 Lingua Franca 54 3.1 Overview...................................... 54 3.2 Target Declaration ................................ 59 3.3 Import Statement................................. 60 3.4 Preamble Block.................................. 60 3.5 Reactor Definition ................................ 61 iii 3.6 Reaction Definition................................ 73 3.7 Banks and Multiports .............................. 74 3.8 Semantics ..................................... 78 4 Concurrency and Timing 83 4.1 Physical Actions in Reactive Systems...................... 84 4.2 Runtime Scheduling and Real-Time Constraints................ 88 4.3 Exposing More Parallelism............................ 91 4.4 Further Optimizations .............................. 94 4.5 Subroutines.................................... 97 4.6 Performance Benchmarks............................. 100 5 Federated Execution 106 5.1 Reasoning About Time.............................. 107 5.2 Decentralized Coordination ........................... 110 5.3 Centralized Coordination............................. 114 5.4 Support for Federated Programs in LF ..................... 114 5.5 Conclusion..................................... 119 6 Conclusion 121 6.1 Further Work................................... 121 6.2 Applications.................................... 126 6.3 Final Remarks................................... 127 Bibliography 128 A Summary of the Reactor Model 147 Index 149 iv List of Algorithms 1 Set a value on port p and trigger reactions................... 33 2 Schedule an action a................................ 34 3 Request execution to come to a halt....................... 36 4 Create a reactor instance given a reactor class and a container instance... 37 5 Start the execution of a reactor......................... 37 6 Delete a given reactor............................... 38 7 Connect port p to downstream port p0 ..................... 38 8 Disconnect p from downstream port p0 ..................... 40 9 Return the reaction graph of reactor r ..................... 41 10 Report the dependencies between all ports in reactor r ............ 43 11 Execute top-level reactor r ............................ 45 12 Execute triggered reactions until QR is empty................. 46 13 Detach and remove defunct reactors from reactor r .............. 48 14 Stop the execution of reactor r .......................... 48 15 Process the next event(s) for a top-level reactor r ............... 49 16 Recursively reset the values of all ports and actions of reactor r to absent.. 49 17 Assign levels to all reactions in a top-level reactor r .............. 89 18 Propagate deadlines between reactions in top-level reactor r ......... 91 19 Assign chain identifiers to reactions in a top-level reactor r .......... 95 v List of Figures 2.1 A reactor implementation of the introductory example. Reactor X has a startup reaction that produces an event on output ports dbl and inc. The second reaction of Y, triggered by input port inc, cannot execute 1) before Relay has reacted; and 2) until after the first reaction of Y has executed in case it was triggered by an event on dbl. ..................................... 19 2.2 A reactor that implements a simplified power train control module. 22 2.3 A reactor implementation of a simple \rock, paper, scissors" game. 44 2.4 A causality loop due to reaction priority....................... 44 2.5 A filtered version of diagram in Figure 2.4...................... 45 3.1 A flow chart describing the Lingua Franca compiler toolchain. 56 3.2 Graphical rendering of the \Hello World" program in Figure 3.7.......... 64 3.3 Timers are syntactic sugar for periodically recurring logical actions. 70 3.4 Constructing a strictly contracting function GN that models an LF program. 82 4.1 Diagram generated from the LF code in Listing 4.1. ............... 84 4.2 A deadline defines the maximum delay between the logical time of an event and the physical time of the start of a reaction that it triggers............. 86 4.3 A diagram of an LF program realizing a typical scatter/gather pattern. 90 4.4 A diagram of a pipeline pattern in LF; each stage executes in parallel. 90 4.5 An example reaction graph with assigned levels and IDs.............. 93 4.6 The reactor equivalent of a subroutine. ...................... 97 4.7 An alternative implementation of Figure 4.6 using a caller and callee port. 98 4.8 Reaction graphs explaining the dependencies in subroutine-like interactions. 99 4.9 A reactor implementation of the Savina PingPong benchmark. 101 4.10 PingPong: a comparison between Akka actors and reactors. 102 4.11 A reactor implementation of the Savina Philosophers benchmark. 103 4.12 A reactor implementation of the Savina Trapezoid benchmark. 103 4.13 Trapezoid: reduced execution time with a larger number of worker threads. 104 4.14 Trapezoid: a comparison between Akka actors and reactors. 105 5.1 A federated reactor that controls an aircraft door. Each reactor runs on a different host........................................... 106 vi 5.2 Different observers may see events in a different order. An additional logical timeline allows to establish a global ordering. After a certain safe-to-process (STP) threshold, Door received all relevant messages and can use the logical timeline to determine that
Load more

Recommended publications
  • The Implementation of Metagraph Agents Based on Functional Reactive Programming
    ______________________________________________________PROCEEDING OF THE 26TH CONFERENCE OF FRUCT ASSOCIATION The Implementation of Metagraph Agents Based on Functional Reactive Programming Valeriy Chernenkiy, Yuriy Gapanyuk, Anatoly Nardid, Nikita Todosiev Bauman Moscow State Technical University, Moscow, Russia [email protected], [email protected], [email protected], [email protected] Abstract—The main ideas of the metagraph data model and there is no doubt that it is the functional approach in the metagraph agent model are discussed. The metagraph programming that makes it possible to make such approach for semantic complex event processing is presented. implementation effectively. Therefore, the work is devoted to The metagraph agent implementation based on Functional the implementation of a multi-agent paradigm using functional Reactive Programming is proposed. reactive programming. The advantage of this implementation is that agents can work in parallel, supporting a functional I. INTRODUCTION reactive paradigm. Currently, models based on complex networks are The article is organized as follows. The section II discusses increasingly used in various fields of science, from the main ideas of the metagraph model. The section III mathematics and computer science to biology and sociology. discusses the metagraph agent model. The section IV discusses According to [1]: “a complex network is a graph (network) the Semantic Complex Event Processing approach and its’ with non-trivial topological features – features that do not occur correspondence to the metagraph model. The section V (which in simple networks such as lattices or random graphs but often is the novel result presented in the article) discusses the occur in graphs modeling of real systems.” The terms “complex metagraph agent implementation based on Functional Reactive network” and “complex graph” are often used synonymously.
    [Show full text]
  • Functional Reactive Programming, Refactored
    Functional Reactive Programming, Refactored Ivan Perez Manuel Barenz¨ Henrik Nilsson University of Nottingham University of Bamberg University of Nottingham [email protected] [email protected] [email protected] Abstract 18] and Reactive Values [21]. Through composition of standard Functional Reactive Programming (FRP) has come to mean many monads like reader, exception, and state, any desirable combination things. Yet, scratch the surface of the multitude of realisations, and of time domain, dynamic system structure,flexible handling of I/O there is great commonality between them. This paper investigates and more can be obtained in an open-ended manner. this commonality, turning it into a mathematically coherent and Specifically, the contributions of this paper are: practical FRP realisation that allows us to express the functionality We define a minimal Domain-Specific Language of causal • of many existing FRP systems and beyond by providing a minimal Monadic Stream Functions (MSFs), give them precise mean- FRP core parametrised on a monad. We give proofs for our theoreti- ing and analyse the properties they fulfill. cal claims and we have verified the practical side by benchmarking We explore the use of different monads in MSFs, how they nat- a set of existing, non-trivial Yampa applications running on top of • our new system with very good results. urally give rise to known reactive constructs, like termination, switching, higher-order, parallelism and sinks, and how to com- Categories and Subject Descriptors D.3.3 [Programming Lan- pose effects at a stream level using monad transformers [15]. guages]: Language Constructs and Features – Control Structures We implement three different FRP variants on top of our frame- • Keywords functional reactive programming, reactive program- work: 1) Arrowized FRP, 2) Classic FRP and 3) Signal/Sink- ming, stream programming, monadic streams, Haskell based reactivity.
    [Show full text]
  • Flapjax: Functional Reactive Web Programming
    Flapjax: Functional Reactive Web Programming Leo Meyerovich Department of Computer Science Brown University [email protected] 1 People whose names should be before mine. Thank you to Shriram Krishnamurthi and Gregory Cooper for ensuring this project’s success. I’m not sure what would have happened if not for the late nights with Michael Greenberg, Aleks Bromfield, and Arjun Guha. Peter Hopkins, Jay McCarthy, Josh Gan, An- drey Skylar, Jacob Baskin, Kimberly Burchett, Noel Welsh, and Lee Butterman provided invaluable input. While not directly involved with this particular project, Kathi Fisler and Michael Tschantz have pushed me along. 1 Contents 4.6. Objects and Collections . 32 4.6.1 Delta Propagation . 32 1. Introduction 3 4.6.2 Shallow vs Deep Binding . 33 1.1 Document Approach . 3 4.6.3 DOM Binding . 33 2. Background 4 4.6.4 Server Binding . 33 2.1. Web Programming . 4 4.6.5 Disconnected Nodes and 2.2. Functional Reactive Programming . 5 Garbage Collection . 33 2.2.1 Events . 6 2.2.2 Behaviours . 7 4.7. Evaluations . 34 2.2.3 Automatic Lifting: Transparent 4.7.1 Demos . 34 Reactivity . 8 4.7.2 Applications . 34 2.2.4 Records and Transparent Reac- 4.8 Errors . 34 tivity . 10 2.2.5 Behaviours and Events: Conver- 4.9 Library vs Language . 34 sions and Event-Based Derivation 10 4.9.1 Dynamic Typing . 34 4.9.2 Optimization . 35 3. Implementation 11 3.1. Topological Evaluation and Glitches . 13 4.9.3 Components . 35 3.1.1 Time Steps . 15 4.9.4 Compilation .
    [Show full text]
  • Incorparating the Actor Model Into SCIVE on an Abstract Semantic Level
    Incorparating the Actor Model into SCIVE on an Abstract Semantic Level Christian Frohlich¨ ∗ Marc E. Latoschik† AI and VR Group, Bielefeld University AI and VR Group, Bielefeld University. ABSTRACT Since visual perception is very important for generating immer- sive environments, most VR applications focus on the graphical This paper illustrates the temporal synchronization and process flow simulation output. Tools like OpenGL Performer, Open Inven- facilities of a real-time simulation system which is based on the ac- tor [12], Open Scene Graph, OpenSG [11] or the VRML successor tor model. The requirements of such systems are compared against X3D [8] are based upon a hierarchical scene graph structure, which the actor model’s basic features and structures. The paper describes allows for complex rendering tasks. Extension mechanisms like how a modular architecture benefits from the actor model on the field routing or rapid prototyping via scipting interfaces allow for module level and points out how the actor model enhances paral- new customized node types and interconnected application graphs. lelism and concurrency even down to the entity level. The actor idea is incorporated into a novel simulation core for intelligent vir- Purpose-built VR application frameworks adopt and extend these mechanisms, by adding in- and output customization, see e.g. tual environments (SCIVE). SCIVE supports well-known and es- TM tablished Virtual Reality paradigms like the scene graph metaphor, Lightning [4], Avango [13], VR Juggler [3] or the CAVELib . field routing concepts etc. In addition, SCIVE provides an explicit Also network distribution paradigms are often integrated to enable semantic representation of its internals as well as of the specific distributed rendering on a cluster architecture, as can be seen in virtual environments’ contents.
    [Show full text]
  • Actor-Based Concurrency by Srinivas Panchapakesan
    Concurrency in Java and Actor- based concurrency using Scala By, Srinivas Panchapakesan Concurrency Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel. Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes. Advantages of Concurrency Almost every computer nowadays has several CPU's or several cores within one CPU. The ability to leverage theses multi-cores can be the key for a successful high-volume application. Increased application throughput - parallel execution of a concurrent program allows the number of tasks completed in certain time period to increase. High responsiveness for input/output-intensive applications mostly wait for input or output operations to complete. Concurrent programming allows the time that would be spent waiting to be used for another task. More appropriate program structure - some problems and problem domains are well-suited to representation as concurrent tasks or processes. Process vs Threads Process: A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time. Threads: Threads are so called lightweight processes which have their own call stack but an access shared data.
    [Show full text]
  • Liam: an Actor Based Programming Model for Hdls
    Liam: An Actor Based Programming Model for HDLs Haven Skinner Rafael Trapani Possignolo Jose Renau Dept. of Computer Engineering Dept. of Computer Engineering Dept. of Computer Engineering [email protected] [email protected] [email protected] ABSTRACT frequency being locked down early in the development process, The traditional model for developing synthesizable digital architec- and adds a high cost in effort and man-hours, to make high-level tures is a clock-synchronous pipeline. Latency-insensitive systems changes to the system. Although these challenges can be managed, are an alternative, where communication between blocks is viewed they represent fundamental obstacles to developing large-scale as message passing. In hardware this is generally managed by con- systems. trol bits such as valid/stop signals or token credit mechanisms. An alternative is a latency-insensitive design, where the system Although prior work has shown that there are numerous benefits is abstractly seen as being comprised of nodes, which communicate to building latency-insensitive digital hardware, a major factor dis- via messages. Synchronous hardware systems can be automatically couraging its use is the difficulty of managing the additional logic transformed to latency-insensitive designs, which we refer to as and infrastructure required to implement it. elastic systems [1–3]. Alternately, the designer can manually con- We propose a new programming paradigm for Hardware Descrip- trol the latency-insensitive backend [4, 5], we call such systems tion Languages, built on the Actor Model, to implicitly implement Fluid Pipelines. The advantage of exposing the elasticity to the latency-insensitive hardware designs. We call this model Liam, for designer is an increase in performance and flexibility in transforma- Latency-Insensitive Actor-based programming Model.
    [Show full text]
  • Computer Science 1
    Computer Science 1 Computer Science Department Website: https://www.cs.uchicago.edu Program of Study The computer science program offers BA and BS degrees, as well as combined BA/MS and BS/MS degrees. Students who earn the BA are prepared either for graduate study in computer science or a career in industry. Students who earn the BS degree build strength in an additional field by following an approved course of study in a related area. The department also offers a minor. Where to Start The Department of Computer Science offers several different introductory pathways into the program. In consultation with their College adviser and the Computer Science Department advisers, students should choose their introductory courses carefully. Some guidelines follow. For students intending to pursue further study in computer science, we recommend CMSC 15100 Introduction to Computer Science I or CMSC 16100 Honors Introduction to Computer Science I as the first course. CMSC 15100 does not assume prior experience or unusually strong preparation in mathematics. Students with programming experience and strong preparation in mathematics should consider CMSC 16100 Honors Introduction to Computer Science I. First-year students considering a computer science major are strongly advised to register for an introductory sequence in the Winter or Spring Quarter of their first year, and it is all but essential that they start the introductory sequence no later than the second quarter of their second year. Students who are not intending to major in computer science, but are interested in getting a rigorous introduction to computational thinking with a focus on applications are encouraged to start with CMSC 12100 Computer Science with Applications I.
    [Show full text]
  • Compiling Real Time Functional Reactive Programming
    Compiling Real Time Functional Reactive Programming Dana N. Xu and Siau-Cheng Khoo Department of Computer Science School of Computing National University of Singapore {xun,khoosc}@comp.nus.edu.sg ABSTRACT 1. INTRODUCTION Most of the past languages for reactive systems are based Reactive systems are required to react in a timely man- on synchronous dataflow. Recently, a new reactive lan- ner to external events. Their use can be found in a broad guage, called Real-Time Functional Reactive Programming range of applications, ranging from high-end consumer prod- (RT-FRP) [18] , has been proposed based on the functional ucts (digital radio, intelligent cookers) to systems used in paradigm. The unique feature of this language is the high- mission-critical applications (such as air-craft and nuclear- level abstraction provided in the form of behaviors for conti- power stations). nuous-time signals, and events for discrete-time signals. RT- Programming these systems poses a great challenge, and FRP also features some performance guarantees in the form a number of programming languages have been proposed of bounded runtime and space usage for each reactive com- over the last two decades. Two main concerns are typically putation step. addressed in these languages. Firstly, some features must In this paper, we propose a new compilation scheme for be available to express signals and events, and how they are RT-FRP. Our compilation scheme is based on two key stages. transformed by the intended reactive systems. Secondly, we In the first stage, we translate RT-FRP program to an in- must be able to show that each reaction could be carried termediate functional code.
    [Show full text]
  • Massachusetts Institute of Technology Artificial Intelligence Laboratory
    MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLIGENCE LABORATORY Working Paper 190 June 1979 A FAIR POWER DOMAIN FOR ACTOR COMPUTATIONS Will Clinger AI Laboratory Working Papers are produced for internal circulation, and may contain information that is, for example, too preliminary or too detailed for formal publication. Although some will be given a limited external distribution, it is not intended that they should be considered papers to which reference can be made in the literature. This report describes research conducted at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for this research was provided in part by the Office of Naval Research of the Department of Defense under Contract N00014-75-C-0522. O MASSAnuTsms INSTTUTE OF TECMGoOry FM DRAFT 1 June 1979 -1- A fair power domain A FAIR POWER DOMAIN FOR ACTOR COMPUTATIONS Will Clingerl 1. Abstract Actor-based languages feature extreme concurrency, allow side effects, and specify a form of fairness which permits unbounded nondeterminism. This makes it difficult to provide a satisfactory mathematical foundation for their semantics. Due to the high degree of parallelism, an oracle semantics would be intractable. A weakest precondition semantics is out of the question because of the possibility of unbounded nondeterminism. The most attractive approach, fixed point semantics using power domains, has not been helpful because the available power domain constructions, although very general, seemed to deal inadequately with fairness. By taking advantage of the relatively complex structure of the actor computation domain C, however, a power domain P(C) can be defined which is similar to Smyth's weak power domain but richer.
    [Show full text]
  • Actor Model of Computation
    Published in ArXiv http://arxiv.org/abs/1008.1459 Actor Model of Computation Carl Hewitt http://carlhewitt.info This paper is dedicated to Alonzo Church and Dana Scott. The Actor model is a mathematical theory that treats “Actors” as the universal primitives of concurrent digital computation. The model has been used both as a framework for a theoretical understanding of concurrency, and as the theoretical basis for several practical implementations of concurrent systems. Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching. The advent of massive concurrency through client- cloud computing and many-core computer architectures has galvanized interest in the Actor model. An Actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other Actors; create a finite number of new Actors; designate the behavior to be used for the next message it receives. There is no assumed order to the above actions and they could be carried out concurrently. In addition two messages sent concurrently can arrive in either order. Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages. November 7, 2010 Page 1 of 25 Contents Introduction ............................................................ 3 Fundamental concepts ............................................ 3 Illustrations ............................................................ 3 Modularity thru Direct communication and asynchrony ............................................................. 3 Indeterminacy and Quasi-commutativity ............... 4 Locality and Security ............................................
    [Show full text]
  • Computer Science (COM S) 1
    Computer Science (COM S) 1 COM S 105B: Short Course in Computer Programming: MATLAB COMPUTER SCIENCE (COM S) (2-0) Cr. 2. Any experimental courses offered by COM S can be found at: Prereq: Com S 104 registrar.iastate.edu/faculty-staff/courses/explistings/ (http:// 8-week course in programming using MATLAB. www.registrar.iastate.edu/faculty-staff/courses/explistings/) COM S 106: Introduction to Web Programming Courses primarily for undergraduates: (3-0) Cr. 3. F.S. Introduction to web programming basics. Fundamentals of developing COM S 101: Orientation web pages using a comprehensive web development life cycle. Learn Cr. R. F.S. to design and code practical real-world homepage programs and earn Introduction to the computer science discipline and code of ethics, Com adequate experience with current web design techniques such as HTML5 S courses, research and networking opportunities, procedures, policies, and cascading style sheets. Students also learn additional programming help and computing resources, extra-curricular activities offered by the languages including JavaScript, jQuery, PHP, SQL, and MySQL. Strategies Department of Computer Science and Iowa State University. Discussion for accessibility, usability and search engine optimization. No prior of issues relevant to student adjustment to college life. Offered on a computer programming experience necessary. satisfactory-fail basis only. Offered on a satisfactory-fail basis only. COM S 107: Windows Application Programming COM S 103: Computer Literacy and Applications (3-0) Cr. 3. F.S. Cr. 4. F.S.SS. Introduction to computer programming for non-majors using a language Introduction to computer literacy and applications. Literacy: Impact of such as the Visual Basic language.
    [Show full text]
  • A Model Based Realisation of Actor Model to Conceptualise an Aid for Complex Dynamic Decision-Making
    A Model based Realisation of Actor Model to Conceptualise an Aid for Complex Dynamic Decision-making Souvik Barat1, Vinay Kulkarni1, Tony Clark2 and Balbir Barn3 1Tata Consultancy Services Research, Pune, India 2Sheffield Hallam University, Sheffield, U.K. 3Middlesex University, London, U.K. {souvik.barat, vinay.vkulkarni}@tcs.com, [email protected], [email protected] Keywords: Organisational Decision Making, Simulation, Actor Model of Computation, Actor based Simulation. Abstract: Effective decision-making of modern organisation requires deep understanding of various aspects of organisation such as its goals, structure, business-as-usual operational processes etc. The large size and complex structure of organisations, socio-technical characteristics, and fast business dynamics make this decision-making a challenging endeavour. The state-of-practice of decision-making that relies heavily on human experts is often reported as ineffective, imprecise and lacking in agility. This paper evaluates a set of candidate technologies and makes a case for using actor based simulation techniques as an aid for complex dynamic decision-making. The approach is justified by enumeration of basic requirements of complex dynamic decision-making and the conducting a suitability of analysis of state-of-the-art enterprise modelling techniques. The research contributes a conceptual meta-model that represents necessary aspects of organisation for complex dynamic decision-making together with a realisation in terms of a meta model that extends Actor model of computation. The proposed approach is illustrated using a real life case study from business process outsourcing industry. 1 INTRODUCTION reports from leading consulting organisations such as McKinsey and Harvard Business Review (Kahneman Modern organisations constantly attempt to meet et al., 2011, Meissner et al.
    [Show full text]