DOCSLIB.ORG

Programming Safely with Weak (And Strong) Consistency

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Programming Safely with Weak (And Strong) Consistency PROGRAMMINGSAFELYWITHWEAK(ANDSTRONG)CONSISTENCY A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by matthew pierson milano August 2020 ©2020 Matthew Pierson Milano Some parts of this dissertation (in particular, Chapters 1 and 2) are based on published work where publishing rights have been transferred to the Association for Computing Machinery. For those parts, the following copyright notices are required: 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. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. For chapter 1 : © 2018 Matthew Milano and Andrew Myers. Publication rights licensed to ACM. For chapter 2 : © 2019 Association for Computing Machinery Chapter 3 is based on published work first appearing under the Leibniz International Proceedings in Informatics (LIPIcs). © 2019 Matthew Milano, Rolph Recto, Tom Magrino, and Andrew C Myers PROGRAMMINGSAFELYWITHWEAK(ANDSTRONG) CONSISTENCY matthew pierson milano Cornell University, 2020 Writing programs against weak consistency is inherently difficult. This dissertation makes the job of writing safe programs against weak consistency easier, by introducing programming languages in which strong guarantees are defended from weakly-consistent influence, and in which programmers can write consistent-by-construction programs atop underlying weakly-consistent replication. The first of these languages is MixT, a new language for writing mixed-consistency transactions. These atomic transactions can operate against data at multiple consistency levels simultaneously, and are equipped with an information-flow type system which guarantees weakly-consistent observations cannot influence strongly-consistent actions. While mixed-consistency transactions can defend strong data from weak observations, they cannot ensure that fully-weak code is itself correct. To address this, we leverage monotonic data types to introduce a core language of datalog-like predicates and triggers. In this language, programmers can write monotonic functions over a set of monotonic shared objects, ultimately resulting in a boolean. These monotonic, boolean-returning functions are stable predicates: once they have become iii true, they remain true for all time. Actions which are predicated on these stable predicates cannot be invalidated by missed or future updates. This monotonic language sits at the core of Derecho, a new system for building strongly-consistent distributed systems via replicated state machines. Derecho’s Shared State Table (SST) implements monotonic datatypes atop Remote Direct Memory Access (RDMA), resulting in a high-performance, asynchronous substrate on which to build Derecho’s monotonic language. Using this SST, we have rephrased the Paxos delivery condition monotonically, granting strong consistency despite the underlying asynchronous replication. Finally Gallifrey exposes the monotonic reasoning properties of Derecho’s core language directly to the user, safely integrating monotonic datatypes into a traditional Java-like programming language. Gallifrey allows any object to be asynchronously replicated via Restrictions to its interface, allow- ing only those operations which are safe to call concurrently. Datatypes shared under these restrictions can be viewed monotonically, using a language of predicates and triggers similar to that at the core of Dere- cho. A novel linear region-based type system enforces that shared object restrictions are respected. iv BIOGRAPHICALSKETCH Matthew Milano was born in New York, New York in 1990. He obtained his Bachelor of Science in Computer Science and Music from Brown University in 2013 and his Masters of Science in Computer Science from Cornell University in 2017. He is a recipient of the 2012 Rose Rosengard Subotnik prize, the 2013 Brown University Senior Prize in Computer Science, an honorable mention for the 2015 National Science Foundation Graduate Research Fellowship, and is a 2015 National Defense Science and Engineering Graduate Fellow. He has been recognized for his service to the Cornell Computer Science Department and his outreach efforts in the community. In his spare time Matthew is an avid reader, board games enthusiast, and academically-trained composer. v ACKNOWLEDGMENTS The kindness and generosity of the people who have surrounded me dur- ing my PhD never ceases to amaze. Without the community surrounding me, attaining a PhD would be nearly impossible. While my research and academic life has been touched by innumerable hands, I would like to single out a few specific individuals who have had an outsized impact on my life and work in graduate school. I first must call out my advisor, Andrew Myers, and my former advisor, Nate Foster. It is hard to overstate the influence your advisor has on you, and I have been blessed to work under two faculty who are dedicated to making sure that I grow into the researcher they always knew (no matter how I doubted) that I could be. Andrew Myers in particular takes special care to let me pick my own directions and follow my own problems, even if it’s not in a direction that he would naturally have taken—and even if it’s not clear that success is in easy reach. And he’s been right there with me every step of the way, ever ready with a guiding hand in case I stumble. Tom Magrino and Isaac Sheff were my original mentors when I arrived at the department, and soon grew into my friends and collaborators. Tom’s expertise in coordination-avoiding systems was instrumental in understanding Gallifrey’s systems challenges, while Isaac’s continued quiet assistance has proven invaluable into the final months of my PhD. vi Rolph Recto, my closest student collaborator and intellectual sparring partner, always pushed me to justify my designs, to consider every avenue and not just go with what seems most natural to me. Key ideas in Gallifrey (chapter 3)—such as the ability to transition between restrictions—are the result of his insistence. The accessibility of Gallifrey has no doubt improved dramatically as a result. Ken Birman has been an incredibly impactful mentor, collaborator, and all-but-advisor since the early years of my PhD. His continued insistence that we shouldn’t settle just for what seems possible has been the driving force uncountable breakthroughs in Derecho, and his tireless advocacy for his students and projects is legendary. I am forever grateful that he chose to include me. Fabian Muehlboeck has been an endless source of inspiration, assistance, and companionship for the duration of my PhD. We spent many late nights together, working through each other’s research problems, playing games, or staying sane. Every idea in this thesis owes something to Fabian, whether it be late-night debugging help or careful assistance with formal material. But the largest thanks must be saved for two primary undergraduate re- search assistants, Patrick LaFontaine and Danny Yang, without whom this dissertation would surely remain incomplete. Patrick took implementation lead in the systems aspects of Gallifrey (chapter 3), integrating shared objects into Antidote’s existing CRDT patterns. Danny is responsible for almost the entire Gallifrey compiler, and continued his contributions for months after his graduation. It is my sincere hope that I see both of them as PhD students some day. vii This research was conducted with Government support under and awarded by DoD, Air Force Office of Scientific Research, National Defense Science and Engineering Graduate (NDSEG) Fellowship, 32 CFR 168a, and by NSF grants 1717554 and 1704788 viii CONTENTS 0 introduction1 0.1 Setting the Stage . 1 0.2 An Overview of Contributions . 4 0.3 Meeting The Mixed-Consistency World with MixT . 5 0.3.1 Where We Are Today . 5 0.3.2 Static Information Flow for Consistency . 8 0.3.3 Mixed-Consistency Transactions . 10 0.3.4 Problems Still Persist . 11 0.4 In Defense of Strong Consistency with Derecho . 11 0.4.1 Existing Solutions . 12 0.4.2 Convergent Programming over RDMA . 15 0.4.3 Derecho: Datacenter Replication at the Speed of Light 17 0.4.4 The Limits of RDMA . 18 0.5 Consistent Programming Over the Wide Area with Gallifrey 19 0.5.1 Systems Solutions with CRDTs . 19 0.5.2 Gallifrey: A New Language for Geodistributed Pro- gramming . 22 0.6 Reasoning about Isolation with Static Types . 25 0.6.1 Existing Type Systems . 25 0.6.2 Isolation Types . 27 0.7 Common Themes . 30 0.8 A Roadmap . 31 1 mixt 33 ix x contents 1.1 Introduction . 33 1.2 Motivation . 36 1.2.1 A Running Example . 36 1.2.2 The Need For Mixed-Consistency Transactions . 37 1.2.3 Mixing Consistency Breaks Strong Consistency . 39 1.3 MixT Transaction Language . 41 1.3.1 MixT Language Syntax . 42 1.3.2 A MixT Example Program . 43 1.3.3 MixT API . 45 1.4 Mixed-Consistency Transactions . 47 1.4.1 Defining Mixed Consistency . 47 1.4.2 Noninterference for Mixed Consistency . 49 1.4.3 Consistency as Information Flow . 51 1.4.4 Transaction Splitting . 52 1.4.5 Whole-Transaction Atomicity . 53 1.5 Formalizing the MixT Language . 55 1.5.1 Desugared Language . 55 1.5.2 Statically Checking Consistency Labels . 57 1.5.3 Transaction Splitting . 58 1.5.4 Enforcing Atomicity in Split Transactions . 60 1.6 Correctness . 65 1.6.1 Mixed Isolation . 65 1.6.2 Mixed Consistency and Noninterference through Splitting . 66 1.6.3 Atomicity through Write Witnesses .
Load more

Recommended publications
  • Little Languages for Little Robots
    Little Languages for Little Robots Matthew C. Jadud Brooke N. Chenoweth Jacob Schleter University of Kent Canterbury Indiana University Gibson High School Canterbury, UK Bloomington Fort Branch, IN [email protected] Bloomington, IN [email protected] ABSTRACT where students learn by building personally meaningful With serendipity as our muse, we have created tools that artifacts in the world. allow students to author languages of their own design for robots of their own construction. In developing a Scheme 2. JACKLL: A NEW LANGUAGE compiler for the LEGO Mindstorm we realized that there In building up to the evolution of Jackll and the philoso- is great educational potential in the design and creation phies its creation embodies, we feel it is appropriate to of new languages for small robotics kits. As a side effect first introduce the LEGO Mindstorm, the target for our of bringing Scheme and the Mindstorm together in a cre- Scheme compiler, and situate Jackll with respect to other ative context, we have begun an exploration of teaching languages intended for beginner programmers. language design that is fundamentally different from the treatment of the subject in traditional literature. 2.1 What is the LEGO Mindstorm? The LEGO Mindstorm Robotics Invention System is a 1. INTRODUCTION commercial product from the LEGO Group that provides Jacob Schleter, a rising senior at Gibson High School, Fort an inexpensive, reconfigurable platform for exploring robotics. Branch, Indiana, took part in the Indiana University Col- It comes standard with two motors, two touch sensors, one lege of Arts and Sciences Summer Research Experience for light sensor, and hundreds of pieces for assembling all sorts six weeks during the summer of 2002.
    [Show full text]
  • How to Design Co-Programs
    JFP, 15 pages, 2021. c Cambridge University Press 2021 1 doi:10.1017/xxxxx EDUCATIONMATTERS How to Design Co-Programs JEREMY GIBBONS Department of Computer Science, University of Oxford e-mail: [email protected] Abstract The observation that program structure follows data structure is a key lesson in introductory pro- gramming: good hints for possible program designs can be found by considering the structure of the data concerned. In particular, this lesson is a core message of the influential textbook “How to Design Programs” by Felleisen, Findler, Flatt, and Krishnamurthi. However, that book discusses using only the structure of input data for guiding program design, typically leading towards structurally recur- sive programs. We argue that novice programmers should also be taught to consider the structure of output data, leading them also towards structurally corecursive programs. 1 Introduction Where do programs come from? This mystery can be an obstacle to novice programmers, who can become overwhelmed by the design choices presented by a blank sheet of paper, or an empty editor window— where does one start? A good place to start, we tell them, is by analyzing the structure of the data that the program is to consume. For example, if the program h is to process a list of values, one may start by analyzing the structure of that list. Either the list is empty ([]), or it is non-empty (a : x) with a head (a) and a tail (x). This provides a candidate program structure: h [ ] = ::: h (a : x) = ::: a ::: x ::: where for the empty list some result must simply be chosen, and for a non-empty list the result depends on the head a and tail x.
    [Show full text]
  • Understanding Distributed Consensus
    What’s Live? Understanding Distributed Consensus∗ Saksham Chand Yanhong A. Liu Computer Science Department, Stony Brook University, Stony Brook, NY 11794, USA {schand,liu}@cs.stonybrook.edu Abstract Distributed consensus algorithms such as Paxos have been studied extensively. They all use the same definition of safety. Liveness is especially important in practice despite well-known theoretical impossibility results. However, many different liveness proper- ties and assumptions have been stated, and there are no systematic comparisons for better understanding of these properties. This paper systematically studies and compares different liveness properties stated for over 30 prominent consensus algorithms and variants. We introduce a precise high- level language and formally specify these properties in the language. We then create a hierarchy of liveness properties combining two hierarchies of the assumptions used and a hierarchy of the assertions made, and compare the strengths and weaknesses of algorithms that ensure these properties. Our formal specifications and systematic comparisons led to the discovery of a range of problems in various stated liveness proper- ties, from too weak assumptions for which no liveness assertions can hold, to too strong assumptions making it trivial to achieve the assertions. We also developed TLA+ spec- ifications of these liveness properties, and we use model checking of execution steps to illustrate liveness patterns for Paxos. 1 Introduction arXiv:2001.04787v2 [cs.DC] 21 Jun 2021 Distributed systems are pervasive, where processes work with each other via message passing. For example, this article is available to the current reader owing to some distributed system. At the same time, distributed systems are highly complex, due to their unpredictable asyn- chronous nature in the presence of failures—processes can fail and later recover, and messages can be lost, delayed, reordered, and duplicated.
    [Show full text]
  • Distributed Consensus Revised
    UCAM-CL-TR-935 Technical Report ISSN 1476-2986 Number 935 Computer Laboratory Distributed consensus revised Heidi Howard April 2019 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2019 Heidi Howard This technical report is based on a dissertation submitted September 2018 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Pembroke College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Distributed consensus revised Heidi Howard Summary We depend upon distributed systems in every aspect of life. Distributed consensus, the abil- ity to reach agreement in the face of failures and asynchrony, is a fundamental and powerful primitive for constructing reliable distributed systems from unreliable components. For over two decades, the Paxos algorithm has been synonymous with distributed consensus. Paxos is widely deployed in production systems, yet it is poorly understood and it proves to be heavyweight, unscalable and unreliable in practice. As such, Paxos has been the subject of extensive research to better understand the algorithm, to optimise its performance and to mitigate its limitations. In this thesis, we re-examine the foundations of how Paxos solves distributed consensus. Our hypothesis is that these limitations are not inherent to the problem of consensus but instead specific to the approach of Paxos. The surprising result of our analysis is a substantial weakening to the requirements of this widely studied algorithm. Building on this insight, we are able to prove an extensive generalisation over the Paxos algorithm.
    [Show full text]
  • Proceedings of the 8Th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (Ed.) Sponsors
    Proceedings of the 8th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (ed.) Sponsors We gratefully acknowledge the support given to the 8th European Lisp Symposium by the following sponsors: WWWLISPWORKSCOM i Organization Programme Committee Julian Padget – University of Bath, UK (chair) Giuseppe Attardi — University of Pisa, Italy Sacha Chua — Toronto, Canada Stephen Eglen — University of Cambridge, UK Marc Feeley — University of Montreal, Canada Matthew Flatt — University of Utah, USA Rainer Joswig — Hamburg, Germany Nick Levine — RavenPack, Spain Henry Lieberman — MIT, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Robert Strandh — University of Bordeaux, France Edmund Weitz — University of Applied Sciences, Hamburg, Germany Local Organization Christophe Rhodes – Goldsmiths, University of London, UK (chair) Richard Lewis – Goldsmiths, University of London, UK Shivi Hotwani – Goldsmiths, University of London, UK Didier Verna – EPITA Research and Development Laboratory, France ii Contents Acknowledgments i Messages from the chairs v Invited contributions Quicklisp: On Beyond Beta 2 Zach Beane µKanren: Running the Little Things Backwards 3 Bodil Stokke Escaping the Heap 4 Ahmon Dancy Unwanted Memory Retention 5 Martin Cracauer Peer-reviewed papers Efficient Applicative Programming Environments for Computer Vision Applications 7 Benjamin Seppke and Leonie Dreschler-Fischer Keyboard? How quaint. Visual Dataflow Implemented in Lisp 15 Donald Fisk P2R: Implementation of
    [Show full text]
  • Distributed Consensus: Performance Comparison of Paxos and Raft
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Distributed Consensus: Performance Comparison of Paxos and Raft HARALD NG KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Distributed Consensus: Performance Comparison of Paxos and Raft HARALD NG Master in Software Engineering of Distributed Systems Date: September 10, 2020 Supervisor: Lars Kroll (RISE), Max Meldrum (KTH) Examiner: Seif Haridi School of Electrical Engineering and Computer Science Host company: RISE Swedish title: Distribuerad Konsensus: Prestandajämförelse mellan Paxos och Raft iii Abstract With the growth of the internet, distributed systems have become increasingly important in order to provide more available and scalable applications. Con- sensus is a fundamental problem in distributed systems where multiple pro- cesses have to agree on the same proposed value in the presence of partial failures. Distributed consensus allows for building various applications such as lock services, configuration manager services or distributed databases. Two well-known consensus algorithms for building distributed logs are Multi-Paxos and Raft. Multi-Paxos was published almost three decades before Raft and gained a lot of popularity. However, critics of Multi-Paxos consider it difficult to understand. Raft was therefore published with the motivation of being an easily understood consensus algorithm. The Raft algorithm shares similar characteristics with a practical version of Multi-Paxos called Leader- based Sequence Paxos. However, the algorithms differ in important aspects such as leader election and reconfiguration. Existing work mainly compares Multi-Paxos and Raft in theory, but there is a lack of performance comparisons in practice. Hence, prototypes of Leader- based Sequence Paxos and Raft have been designed and implemented in this thesis.
    [Show full text]
  • 42 Paxos Made Moderately Complex
    Paxos Made Moderately Complex ROBBERT VAN RENESSE and DENIZ ALTINBUKEN, Cornell University This article explains the full reconfigurable multidecree Paxos (or multi-Paxos) protocol. Paxos is by no means a simple protocol, even though it is based on relatively simple invariants. We provide pseudocode and explain it guided by invariants. We initially avoid optimizations that complicate comprehension. Next we discuss liveness, list various optimizations that make the protocol practical, and present variants of the protocol. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Syst- ems—Network operating systems; D.4.5 [Operating Systems]: Reliability—Fault-tolerance General Terms: Design, Reliability Additional Key Words and Phrases: Replicated state machines, consensus, voting ACM Reference Format: Robbert van Renesse and Deniz Altinbuken. 2015. Paxos made moderately complex. ACM Comput. Surv. 47, 3, Article 42 (February 2015), 36 pages. DOI: http://dx.doi.org/10.1145/2673577 1. INTRODUCTION Paxos [Lamport 1998] is a protocol for state machine replication in an asynchronous environment that admits crash failures. It is useful to consider the terms in this 42 sentence carefully: —A state machine consists of a collection of states, a collection of transitions between states, and a current state. A transition to a new current state happens in response to an issued operation and produces an output. Transitions from the current state to the same state are allowed and are used to model read-only operations. In a deterministic state machine, for any state and operation, the transition enabled by the operation is unique and the output is a function only of the state and the operation.
    [Show full text]
  • Essentials of Compilation an Incremental Approach
    Essentials of Compilation An Incremental Approach Jeremy G. Siek, Ryan R. Newton Indiana University with contributions from: Carl Factora Andre Kuhlenschmidt Michael M. Vitousek Michael Vollmer Ryan Scott Cameron Swords April 2, 2019 ii This book is dedicated to the programming language wonks at Indiana University. iv Contents 1 Preliminaries 5 1.1 Abstract Syntax Trees and S-expressions . .5 1.2 Grammars . .7 1.3 Pattern Matching . .9 1.4 Recursion . 10 1.5 Interpreters . 12 1.6 Example Compiler: a Partial Evaluator . 14 2 Integers and Variables 17 2.1 The R1 Language . 17 2.2 The x86 Assembly Language . 20 2.3 Planning the trip to x86 via the C0 language . 24 2.3.1 The C0 Intermediate Language . 27 2.3.2 The dialects of x86 . 28 2.4 Uniquify Variables . 28 2.5 Remove Complex Operators and Operands . 30 2.6 Explicate Control . 31 2.7 Uncover Locals . 32 2.8 Select Instructions . 32 2.9 Assign Homes . 33 2.10 Patch Instructions . 34 2.11 Print x86 . 35 3 Register Allocation 37 3.1 Registers and Calling Conventions . 38 3.2 Liveness Analysis . 39 3.3 Building the Interference Graph . 40 3.4 Graph Coloring via Sudoku . 42 3.5 Print x86 and Conventions for Registers . 48 v vi CONTENTS 3.6 Challenge: Move Biasing∗ .................... 48 4 Booleans and Control Flow 53 4.1 The R2 Language . 54 4.2 Type Checking R2 Programs . 55 4.3 Shrink the R2 Language . 58 4.4 XOR, Comparisons, and Control Flow in x86 . 58 4.5 The C1 Intermediate Language .
    [Show full text]
  • Efficient Applicative Programming Environments for Computer Vision
    Efficient Applicative Programming Environments for Computer Vision Applications Integration and Use of the VIGRA Library in Racket Benjamin Seppke Leonie Dreschler-Fischer University of Hamburg University of Hamburg Dept. Informatics Dept. Informatics Vogt-Kölln-Str. 30 Vogt-Kölln-Str. 30 22527 Hamburg, Germany 22527 Hamburg, Germany [email protected] [email protected] ABSTRACT 1. INTRODUCTION Modern software development approaches, like agile soft- Although applicative programming languages have a long ware engineering, require adequate tools and languages to tradition, they still do not belong to the scrap heap. In- support the development in a clearly structured way. At stead, they have proven to support state-of-the-art devel- best, they shall provide a steep learning curve as well as opment approaches by means of an interactive development interactive development environments. In the field of com- cycle, genericity and simplicity. The influence of applicative puter vision, there is a major interest for both, general re- programming paradigms is even observable in modern lan- search and education e.g. of undergraduate students. Here, guages, like Python, Dart and Go. However, there are some one often has to choose between understandable but compa- research areas, which are computationally of high costs and rably slow applicative programming languages, like Racket are thus currently less supported by applicative program- and fast but unintuitive imperative languages, like C/C++. ming languages. In this paper we present a system, which combines the best of each approaches with respect to common tasks in com- In this paper, we select the research field of computer vision puter vision, the applicative language Racket and the VI- and show how to connect applicative languages to a generic GRA C++ library.
    [Show full text]
  • Kent Academic Repository Full Text Document (Pdf)
    Kent Academic Repository Full text document (pdf) Citation for published version Chitil, Olaf (2009) Functional Programming. In: Wah, Benjamin W., ed. Encyclopedia of Computer Science and Engineering. John Wiley & Sons, Hoboken, NJ, pp. 1334-1344. ISBN 978-0-471-38393-2. DOI Link to record in KAR https://kar.kent.ac.uk/24064/ Document Version UNSPECIFIED Copyright & reuse Content in the Kent Academic Repository is made available for research purposes. Unless otherwise stated all content is protected by copyright and in the absence of an open licence (eg Creative Commons), permissions for further reuse of content should be sought from the publisher, author or other copyright holder. Versions of research The version in the Kent Academic Repository may differ from the final published version. Users are advised to check http://kar.kent.ac.uk for the status of the paper. Users should always cite the published version of record. Enquiries For any further enquiries regarding the licence status of this document, please contact: [email protected] If you believe this document infringes copyright then please contact the KAR admin team with the take-down information provided at http://kar.kent.ac.uk/contact.html Functional Programming Olaf Chitil University of Kent, United Kingdom Abstract Functional programming is a programming paradigm like object-oriented pro- gramming and logic programming. Functional programming comprises both a spe- cific programming style and a class of programming languages that encourage and support this programming style. Functional programming enables the programmer to describe an algorithm on a high-level, in terms of the problem domain, without having to deal with machine-related details.
    [Show full text]
  • CS5412: Lecture II How It Works
    CS5412 Spring 2016 (Cloud Computing: Birman) 1 CS5412: PAXOS Lecture XIII Ken Birman Leslie Lamport’s vision 2 Centers on state machine replication We have a set of replicas that each implement some given, deterministic, state machine and we start them in the same state Now we apply the same events in the same order. The replicas remain in the identical state To tolerate ≤ t failures, deploy 2t+1 replicas (e.g. Paxos with 3 replicas can tolerate 1 failure) How best to implement this model? CS5412 Spring 2016 (Cloud Computing: Birman) Two paths forwards... 3 One option is to build a totally ordered reliable multicast protocol, also called an “atomic broadcast” protocol in some papers To send a request, you give it to the library implementing that protocol (for cs5412: probably Vsync). Eventually it does upcalls to event handlers in the replicated application and they apply the event In this approach the application “is” the state machine and the multicast “is” the replication mechanism Use “state transfer” to initialize a joining process if we want to replace replicas that crash CS5412 Spring 2016 (Cloud Computing: Birman) Two paths forwards... 4 A second option, explored in Lamport’s Paxos protocol, achieves a similar result but in a very different way We’ll look at Paxos first because the basic protocol is simple and powerful, but we’ll see that Paxos is slow Can speed it up... but doing so makes it very complex! The basic, slower form of Paxos is currently very popular Then will look at faster but more complex reliable multicast options (many of them...) CS5412 Spring 2016 (Cloud Computing: Birman) Key idea in Paxos: Quorums 5 Starts with a simple observation: Suppose that we lock down the membership of a system: It has replicas {P, Q, R, ..
    [Show full text]
  • The Racket Manifesto∗
    The Racket Manifesto∗ Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi Eli Barzilay, Jay McCarthy, Sam Tobin-Hochstadt Abstract The creation of a programming language calls for guiding principles that point the developers to goals. This article spells out the three basic principles behind the 20-year development of Racket. First, programming is about stating and solving problems, and this activity normally takes place in a context with its own language of discourse; good programmers ought to for- mulate this language as a programming language. Hence, Racket is a programming language for creating new programming languages. Second, by following this language-oriented approach to programming, systems become multi-lingual collections of interconnected components. Each language and component must be able to protect its specific invariants. In support, Racket offers protection mechanisms to implement a full language spectrum, from C-level bit manipulation to soundly typed extensions. Third, because Racket considers programming as problem solving in the correct language, Racket also turns extra-linguistic mechanisms into linguistic constructs, especially mechanisms for managing resources and projects. The paper explains these principles and how Racket lives up to them, presents the evaluation framework behind the design process, and concludes with a sketch of Racket’s imperfections and opportunities for future improvements. 1998 ACM Subject Classification D.3.3 Language Constructs and Features Keywords and phrases design
    [Show full text]