DOCSLIB.ORG

Actor Model and Data Flow Programming Paradigm (Using Ported Network Graphs)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Actor Model and Data Flow Programming Paradigm (using Ported Network Graphs) Brett Viren Physics Department DUNE DAQ DFWG – 21 Feb 2020 Outline Actor Model Data Flow Programming Paradigm Brett Viren (BNL) actor + graph 21 Feb 2020 2 / 22 Motivation Our distributed DAQ software needs cohesive design patterns in order to keep software development, configuration, operation, etc manageable. The DAQ workshop began the process of discussing some likely patterns and many of them are already in use in existing DUNE-related offline and online software. This presentation covers two such patterns identified in our recent discussions. Brett Viren (BNL) actor + graph 21 Feb 2020 3 / 22 Two Behavioral Structure Patterns • Actor Model describes a set of independent code units that intercommunicate asynchronously. • Data Flow Programming Paradigm describes a graph with edges providing data transfer between nodes representing code units. ! Will specialize “graph” into “ported graph” (PGraph) and then “ported network graph” (PNGraph). It is natural, but not required, to implement DFP nodes as actors. Brett Viren (BNL) actor + graph 21 Feb 2020 4 / 22 Actor Model Actor Model (Hewitt, Bishop, Steiger, 1973) «thread» Application creates Actor Function Socket pipe Socket pipe Thread actor actor_function ( pipe, userdata ) An actor is a function started in a thread communicat- ing with its creator over a bidirectional pipe following a message passing protocol. • Typically, the actor function is called with some user data to use for configuration/initialization. • The pipe is an exclusive-pair of connected sockets, one end for the actor and one end for the application. • After thread launch, the pipe is a tether for actor protocol with app. Typically, the actor protocol is very simple. • The actor may also communicate with other actors or in general with the “outside word”. Brett Viren (BNL) actor + graph 21 Feb 2020 5 / 22 Actor Model Simple Actor Protocol and Lifetime • App and actor communicate over a pipe (pipe not explicitly drawn) Application World Actor • The “ready” message allows app to delay, create typically actor notifies immediately. ready • App then goes on to do other things. message • Actor enters its “main loop”: process external go do other input, computes, polls pipe for input from app. things compute • App sends “terminate” via pipe, actor performs message any cleanup and the actor function exits. terminate • Actor may also shutdown on its own but still waits shutdown for “terminate” prior to function exit. • Some cases may need more complexity. Application World ! Actor protocol may be more complex. ! App may have many actors. Actor ! Actors may have actors. ! App may respond to actor termination. Brett Viren (BNL) actor + graph 21 Feb 2020 6 / 22 Actor Model Synchronous API to Asynchronous Actor Protocol A detail: API X Actors are nicely object oriented, simplifying app Implementation by hiding behavior. × But, now app must have actor protocol message Application API pipe handling code! Actor construct • Hide message handling behind synchronous API. create method ◦ App calls method, API sends message, waits to call recv() reply (if appropriate), interprets message, msg returns result to app, app continues. msg • Fact of life, not all async can be totally hidden. method return ◦ Expose pipe to app for explicit polling. ◦ Provide a poll() type method, app calls Application API pipe periodically. Either returns value from oldest recv() message sitting in socket queue or a Actor “false” result when queue is empty. Brett Viren (BNL) actor + graph 21 Feb 2020 7 / 22 Data Flow Programming Paradigm Data Flow Programming Paradigm Structure overall job as code units which receive and/or send data to other code units forming a directed (and possibly cyclic) graph. “Program” by drawing lines (graph edges) between code units (graph nodes). Simplistic view of DFP paradigm. Brett Viren (BNL) actor + graph 21 Feb 2020 8 / 22 Data Flow Programming Paradigm Ported Graph Specialize from simple, directed graph to ported graph. in B1 out o1 i1 A C o2 i2 in B2 out A port is an identified, edge-attachment point on a node. Depending on the DFP system policy, a port may: • follow a specific protocol (flow-in, flow-out, query/response, etc). • pass only specific data types or operate in a type-free manner. • restrict edge multiplicity (allow zero, require exactly one, allow multiple). Note: policy requires validation! Think on ways to perform this. Brett Viren (BNL) actor + graph 21 Feb 2020 9 / 22 Data Flow Programming Paradigm Ported Graph Abstraction A powerful, practical feature of ported graphs in B1 out o1 B1:out A −! X o2 B2:out in B2 out X represents all of A and the input ports of B1 and B2. • A ported subgraph can be abstracted by “removing” all fully-populated ports and presenting a new graph with fewer nodes and ports. • Resulting subgraph is (apparently) much simpler. • In practice: experts configure their subsystems in detail and provide abstracted subgraphs. These are connected to produce another graph which can be abstracted, etc, until the entire system is configured. Note: allows validation the divide-and-conquer strategy. Brett Viren (BNL) actor + graph 21 Feb 2020 10 / 22 Data Flow Programming Paradigm Ported Network Graph Networking adds some complexity. tcp://a.b.c.d:1234 tcp://a.b.c.e:1236 in B1 out o1 i1 A C o2 i2 in B2 out tcp://a.b.c.d:1235 tcp://a.b.c.e:1237 mark bind() as • and connect() as • Networking requires a socket to bind() or connect() via an address. • PNGraph edges must conceptually “pass through” this address. • An address is a node, thus PNGraphs are bipartite: ◦ ported nodes: data transformation ◦ address nodes: data transportation. Brett Viren (BNL) actor + graph 21 Feb 2020 11 / 22 Data Flow Programming Paradigm Address Resolution Network addressing makes PNGraphs more complex than PGraphs. Specifying explicit addresses is brittle (eg, collisions are possible). in B1 out o1 (A,o1) i1 A (C,i1) C o2 i2 in B2 out (A,o2) (C,i2) Robust simplicity: discover addresses given node/port names. • Every port known by (node, port) name 2-tuple. • bind() needs no configuration, pick first unused TPC/IP port number. ◦ publish 3-tuple: (node, port, address) • connect() configured with 2-tuple: (node, port) names ◦ Ports resolve node/port names to address via discovery mechanism. Brett Viren (BNL) actor + graph 21 Feb 2020 12 / 22 Data Flow Programming Paradigm Node Resolution Further abstraction and simplification: peers discover port addresses based on attribute matching rules instead of hard-wiring (node,port) name 2-tuple in configuration. • Node publishes arbitrary key/value attributes (“discovery headers”). ◦ A node may have a “type” or a “role” or a “class” or “category” or a “favorite color”.... • Peers discover node attributes and apply attribute matching rules. • Matching port addresses also held in node’s “discovery headers”. ! Peer, “I want to connect to all PUB ports of Hit Finders of APA 123” ! Discovery mechanism, “you want this list of addresses: [...]” Brett Viren (BNL) actor + graph 21 Feb 2020 13 / 22 Data Flow Programming Paradigm Discovery Mechanisms Two basic approaches: • centralized service (eg DNS), service bind to “well known address”, peer must connect and CRUD records and propagation may be required if service is redundant (latency). Peer must poll/query service to learn records of other peers. • distributed protocol (eg Zyre), “network is the service”, peer publishes to the network, peers get immediate updates (no poll/query), no single point of failure, fundamental redundancy, sub-second latency possible. Bonus: network learns when peers appear, disappear or go quiet. Note: Zyre is implemented as a ZeroMQ actor, so an application or individual node can use it with very little coding to worry about. Brett Viren (BNL) actor + graph 21 Feb 2020 14 / 22 Data Flow Programming Paradigm Modeling Our Graphs Even with simplifying strategies, our graphs will still be complex. We should develop a way to model our graphs independent from “merely” producing configuration files. • Express model in some data language. ◦ (eg, PTMP and Wire-Cell Toolkit uses Jsonnet) • Maintain models in version control. ◦ (use a text-based modeling language) • Develop parameterized models (eg, “use Napa per TC alg”). ◦ (eg, exploit Jsonnet’s functional programming) • Produce visualization for debugging model and for operational displays. ◦ (Jsonnet to GraphViz dot conversion is easy and exists) • Validate policy (eg, find unconnected ports). ◦ (eg. apply constraints with Jsonnet functions). • Transform to applications configuration files/objects. ◦ (eg, compile to JSON, load to DB, load Jsonnet directly, etc) Brett Viren (BNL) actor + graph 21 Feb 2020 15 / 22 Data Flow Programming Paradigm ZIO: an implementation of Ported Network Graph ZIO is a next generation PTMP and also applies to problems with highly parallel offline applications (Wire-Cell Toolkit). It supports Ported Network Graph pattern with three classes: • Node an identified, coherent set of ports, provides port creation, online/offline transitions. • Port a light wrapper around a ZeroMQ socket, bind()/connect(), online/offline. • Peer a simplifying wrapper around ZeroMQ’s Zyre mechanism, discovery header caching and matching. Available in Python and C++ flavors. Both taste similar. https://brettviren.github.io/zio Brett Viren (BNL) actor + graph 21 Feb 2020 16 / 22 Data Flow Programming Paradigm ZIO node/port/peer Example Here, in Python, C++ is similar. node= zio.Node("nodename") log= node.port("logger", zmq.PUB) log.bind() node.online(favorite_color="purple") msg= zio.Message(...) log.send(msg) node= zio.Node("other") port= node.port("slurp", zmq.SUB) port.connect("nodename","logger") node.online() logmsg= port.recv() A zio.Peer is used inside zio.Node to resolve (node,port) to an address. Resolution can be extended to support node resolution described above. Brett Viren (BNL) actor + graph 21 Feb 2020 17 / 22 Last Slide • Actor Model and the DFP paradigm in general and the Ported Network Graph pattern in particular, are two behavioral structure patterns which are central to distributed systems.
Recommended publications
  • Incorparating the Actor Model Into SCIVE on an Abstract Semantic Level

    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.
  • Actor-Based Concurrency by Srinivas Panchapakesan

    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.
  • Liam: an Actor Based Programming Model for Hdls

    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.
  • Massachusetts Institute of Technology Artificial Intelligence Laboratory

    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.
  • Actor Model of Computation

    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 ............................................
  • Computer Science (COM S) 1

    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.
  • 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

    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.
  • An Evaluation of Interaction Paradigms for Active Objects

    An Evaluation of Interaction Paradigms for Active Objects

    An Evaluation of Interaction Paradigms for Active Objects Farzane Karami, Olaf Owe, Toktam Ramezanifarkhani Department of Informatics, University of Oslo, Norway Abstract Distributed systems are challenging to design properly and prove correctly due to their heterogeneous and distributed nature. These challenges depend on the programming paradigms used and their semantics. The actor paradigm has the advantage of offering a modular semantics, which is useful for composi- tional design and analysis. Shared variable concurrency and race conditions are avoided by means of asynchronous message passing. The object-oriented paradigm is popular due to its facilities for program structuring and reuse of code. These paradigms have been combined by means of concurrent objects where remote method calls are transmitted by message passing and where low- level synchronization primitives are avoided. Such kinds of objects may exhibit active behavior and are often called active objects. In this setting the concept of futures is central and is used by a number of languages. Futures offer a flexible way of communicating and sharing computation results. However, futures come with a cost, for instance with respect to the underlying implementation support, including garbage collection. In particular this raises a problem for IoT systems. The purpose of this paper is to reconsider and discuss the future mechanism and compare this mechanism to other alternatives, evaluating factors such as expressiveness, efficiency, as well as syntactic and semantic complexity including ease of reasoning. We limit the discussion to the setting of imperative, active objects and explore the various mechanisms and their weaknesses and advan- tages. A surprising result (at least to the authors) is that the need of futures in this setting seems to be overrated.
  • A Universal Modular ACTOR Formalism for Artificial Intelligence

    A Universal Modular ACTOR Formalism for Artificial Intelligence

    Session 8 Formalisms for Artificial Intelligence A Universal Modular ACTOR Formalism for Artificial Intelligence Carl Hewitt Peter Bishop __ Richard Steiger Abstract This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors [or, if you will, virtual processors, activation frames, or streams]. The formalism makes no presuppositions about the representation of primitive data structures and control structures. Such structures can be programmed, micro-coded, or hard wired in a uniform modular fashion. In fact it is impossible to determine whether a given object is "really" represented as a list, a vector, a hash table, a function, or a process. The architecture will efficiently run the coming generation of PLANNER-like artificial intelligence languages including those requiring a high degree of parallelism. The efficiency is gained without loss of programming generality because it only makes certain actors more efficient; it does not change their behavioral characteristics. The architecture is general with respect to control structure and does not have or need goto, interrupt, or semaphore primitives. The formalism achieves the goals that the disallowed constructs are intended to achieve by other more structured methods. PLANNER Progress "Programs should not only work, but they should appear to work as well." PDP-1X Dogma The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one_ fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script.
  • An Actor Model of Concurrency for the Swift Programming Language

    An Actor Model of Concurrency for the Swift Programming Language

    An Actor Model of Concurrency for the Swift Programming Language Kwabena Aning Keith Leonard Mannock Department of Computer Science and Department of Computer Science and Information Systems Information Systems Birkbeck, University of London Birkbeck, University of London London, WC1E 7HX, UK London, WC1E 7HX, UK Email: [email protected] Email: [email protected] Keywords—Software Architectures, Distributed and Parallel that would enhance the functionality of the language while Systems, Agent Architectures, Programming languages, Concur- addressing concurrent processing issues. rent computing. In the Section II, we will make a distinction between Abstract—The Swift programming language is rapidly rising concurrency and parallelism. In Section III of this paper in popularity but it lacks the facilities for true concurrent we describe our architecture that addresses the problems programming. In this paper we describe an extension to the language which enables access to said concurrent capabilities and with concurrency, problems arising from non-determinism, provides an api for supporting such interactions. We adopt the deadlocking, and divergence, which leads to a more general ACTOR model of concurrent computation and show how it can problem of shared data in a concurrent environment. In Section be successfully incorporated into the language. We discuss early IV we outline our implementation, and our message passing findings on our prototype implementation and show its usage strategy as a possible solution to the shared data problem. via an appropriate example. This work also suggests a general design pattern for the implementation of the ACTOR model in In Section V we describe a brief example to show the usage the Swift programming language.
  • Embedding Concurrency: a Lua Case Study

    Embedding Concurrency: a Lua Case Study

    ISSN 0103-9741 Monografias em Cienciaˆ da Computac¸ao˜ no 13/11 Embedding Concurrency: A Lua Case Study Alexandre Rupert Arpini Skyrme Noemi de La Rocque Rodriguez Pablo Martins Musa Roberto Ierusalimschy Bruno Oliveira Silvestre Departamento de Informatica´ PONTIF´ICIA UNIVERSIDADE CATOLICA´ DO RIO DE JANEIRO RUA MARQUESˆ DE SAO˜ VICENTE, 225 - CEP 22451-900 RIO DE JANEIRO - BRASIL Monografias em Cienciaˆ da Computac¸ao,˜ No. 13/11 ISSN: 0103-9741 Editor: Prof. Carlos Jose´ Pereira de Lucena September, 2011 Embedding Concurrency: A Lua Case Study Alexandre Rupert Arpini Skyrme Noemi de La Rocque Rodriguez Pablo Martins Musa Roberto Ierusalimschy Bruno Oliveira Silvestre1 1 Informatics Institute – Federal University of Goias (UFG) [email protected] , [email protected] , [email protected] , [email protected] , [email protected] Resumo. O suporte a` concorrenciaˆ pode ser considerado no projeto de uma linguagem de programac¸ao˜ ou provido por construc¸oes˜ inclu´ıdas, frequentemente por meio de bib- liotecas, a uma linguagem sem suporte ou com suporte limitado a funcionalidades de concorrencia.ˆ A escolha entre essas duas abordagens nao˜ e´ simples: linguagens com suporte nativo a` concorrenciaˆ oferecem eficienciaˆ e eleganciaˆ de sintaxe, enquanto bib- liotecas oferecem mais flexibilidade. Neste artigo discutimos uma terceira abordagem, dispon´ıvel em linguagens de script: embutir a concorrencia.ˆ Nos´ utilizamos a linguagem de programac¸ao˜ Lua e explicamos os mecanismos que ela oferece para suportar essa abordagem. Em seguida, utilizando dois sistemas concorrentes como exemplos, demon- stramos como esses mecanismos podem ser uteis´ na criac¸ao˜ de modelos leves de con- correncia.ˆ Palavras-chave: concorrencia,ˆ Lua, embutir, estender, scripting, threads, multithreading Abstract.
  • Reactive Messaging Patterns with the Actor Model

    Reactive Messaging Patterns with the Actor Model

    Reactive Messaging Patterns with the Actor Model This page intentionally left blank Reactive Messaging Patterns with the Actor Model Applications and Integration in Scala and Akka Vaughn Vernon New York • Boston • Indianapolis • San Francisco Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liabil- ity is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data Vernon, Vaughn. Reactive messaging patterns with the Actor model : applications and integration in Scala and Akka / Vaughn Vernon. pages cm Includes bibliographical references and index.