Contemporary Approaches to Fault Tolerance

Total Page:16

File Type:pdf, Size:1020Kb

Contemporary Approaches to Fault Tolerance news Science | DOI:10.1145/1538788.1538794 Alex Wright Contemporary Approaches N to Fault Tolerance Thanks to computer scientists like Barbara Liskov, researchers are making major progress with cost-efficient fault tolerance for Web-based systems. S MORE AND more data moves The Byzantine Generals Problem. into the cloud, many de- velopers find themselves Figure 1 Figure 2 grappling with the pros- Lieutenant 2 as the Traitor Commander as the Traitor pect of system failure at ever-widening scales. A Commander Commander When distributed systems first started appearing in the late 1970s and early 1980s, they typically involved a small, fixed number of servers running “Attack” “Attack” “Attack” “Retreat” in a carefully managed environment. By contrast, today’s Web-based distrib- uted systems often involve thousands or hundreds of thousands of servers Lieutenant 1 Lieutenant 2 Lieutenant 1 Lieutenant 2 coming on and offline at unpredict- “He said “He said able intervals, hosting multiple stored retreat” retreat” objects, services, and applications that 1982) DOI: 10.1145/357172.357176 often cross organizational boundaries uly In the Byzantine Generals Problem, as defined by Leslie Lamport, Robert Shostak, and over the Internet. 3 (J Marshall Pease in their 1982 paper, a general must communicate his order to attack or retreat “In a cloud we have relatively few to his lieutenants, but any number of participants, including the general, could be a traitor. SSUE .4, I sites that are loaded with a huge num- OL ber of processors,” says Danny Dolev, volves trade-offs in terms of cost, per- Fortunately, the research commu- a computer science professor at The formance, and development time. nity has been making major strides Hebrew University of Jerusalem. “Fault As Web systems grow, those trade- in this area of late, thanks in part to ” ACM TOPLAS V TOPLAS ” ACM tolerance needs to provide survivability offs loom larger and larger. “Fault-tol- the contributions of ACM A.M. Turing and security within a cloud and across erant systems have always been diffi- Award winner Barbara Liskov of Mas- ROBLEM P clouds.” cult to build,” says University of North sachusetts Institute of Technology, In this deeply intertwined environ- Carolina at Chapel Hill computer sci- whose breakthrough work in applying enerals G ment, software designers have to plan ence professor Mike Reiter. “Getting Byzantine fault tolerance (BFT) meth- for a bewildering array of potential a fault-tolerant system to perform as ods to the Internet has helped point ANTINE Z Y B failure points. Building large-scale well as a non-fault-tolerant one is a the way to cost-efficient fault tolerance E “Th fault-tolerant systems inevitably in- challenge.” for Web-based systems. JULY 2009 | VOL. 52 | NO. 7 | COMMUNICATIONS OF THE ACM 13 news While researchers have developed ization by Leslie Lamport and later underlie most contemporary work on a number of different approaches to surveyed by Fred Schneider. Lamport’s fault tolerance. However, most of these fault tolerance over the years, ultimate- work eventually led to the Paxos pro- projects involved relatively small, fixed ly they all share a common strategy: tocol, a descendant of which is now in clusters of machines. “In this environ- redundancy. While hardware systems use at Google and elsewhere. Lamport ment you only had to worry that the can employ redundancy at multiple lev- used the term “Byzantine” to describe machine you stored your data on might els, such as the central processing unit, the array of possible faults that could have crashed,” Liskov recalls, “but it memory, and firmware, fault-tolerant bedevil a system. The term derives wasn’t going to tell you lies.” software design largely comes down from the Byzantine Generals Problem, With the rise of the Internet in the to creating mechanisms for consistent a logic puzzle in which a group of gen- mid-1990s, the problem of “lies”— data replication. erals must agree on a battle plan, even or malicious hacks—rose to the fore. One of the most common ap- though one or more of the generals Whereas once state machines could proaches to software replication in- may be a traitor. The challenge is to trust each other’s messages, they now volves a method known as state ma- develop an effective messaging sys- had to support an additional layer of chine replication. With state machine tem that will outsmart the traitors and confirmation to allow for the possibil- replication, any service provided by a ensure execution of the battle plan. ity that one or more of the state ma- computer can be described as a state The solution, in a nutshell, involves chines might have been hacked. machine, which accepts commands redundancy. Two groups of developers began ex- from other client machines that alter While Lamport’s work has proved ploring ways of applying state-machine the state machine. By deploying a set foundational in the subsequent devel- replication techniques to cope with a of replica state machines with identi- opment of Byzantine fault tolerance, growing range of Byzantine failures. cal initial states, subsequent client the basic ideas behind state machine Dahlia Malkhi and Mike Reiter intro- commands can be processed by the replication were also implemented in duced a data-centric approach known replicas in a pre-determined fashion, other early systems. In the early 1980s, as the Byzantine quorum systems prin- so that all state machines eventually Ken Birman pursued a related line ciple. In contrast to active-replication reach the same state. Thus, the fail- of work known as Virtual Synchrony approaches like the Paxos protocol, ure of any one state machine can be with the ISIS system. This approach Byzantine quorum systems focus on masked by the surviving machines. establishes rules for replication that identifying a set of servers, rather than The origins of this approach to behave indistinguishably from a non- focusing on the messages, and choos- fault tolerance stretch back to the replicated system running on a single, ing a set of servers so that they intersect 1970s when researchers at SRI Inter- nonfaulty node. The ISIS approach in specific ways to ensure redundancy. national began exploring the question eventually found its way into several In the mid-1990s, Liskov started of how to fly mission-critical aircraft other systems, including the CORBA her breakthrough work on practi- using an assembly of computers. That fault-tolerance architecture. cal Byzantine fault tolerance (PBFT), work laid the foundation for contem- At about the same time, Liskov de- an extension of her earlier work on porary approaches to fault tolerance veloped viewstamped replication, a viewstamped replication that adapted by establishing the fundamental dif- protocol designed to address benign the Paxos replication protocol to cope ference between timely systems, in failures, such as when a message gets with arbitrary failures. Liskov’s ap- which network transmission times lost but there’s no malicious intent. proach demonstrated that Byzantine are bounded and clocks are synchro- These pioneering efforts all laid the approaches could scale cost-effective- nized, and asynchronous systems, in foundation for an approach to state ly, sparking renewed interest in the which communication latencies have machine replication that continues to systems research community. infinite-tail distribution (most mes- While the foundational principles sages arrive within a certain time limit of consistency and replication remain but, with decreasingly low probability, Practical Byzantine essential, the rapid growth of Web sys- messages may be delayed in transit tems is introducing important new beyond any bound). fault tolerance challenges. Many researchers are find- The SRI work also helped draw im- provides a useful ing that PBFT provides a useful frame- portant distinctions between the vari- work for developing fault-tolerant Web ous types of faults experienced in a framework for systems. “I’m really excited about the system, such as message omissions, developing recent work Barbara and her colleagues machine crashes, or arbitrary faults have done on making Byzantine Agree- due to software malfunction or other fault-tolerant ment into a practical tool—one that we undetected data alterations. Finally, Web systems. can use even in large-scale settings,” the SRI work helped to characterize says Birman, a professor of computer resilience bounds, or how many ma- science at Cornell University. chines are needed to tolerate certain Inspired by Lamport and Liskov’s failures. foundational work, Hebrew Universi- The idea of state machine replica- ty’s Dolev has been working on an ap- tion was given its first abstract formal- proach involving polynomial solutions 14 COMMUNICATIONS OF THE ACM | JULY 2009 | VOL. 52 | NO. 7 news to the general Byzantine agreement Cloud Computing problem. While his early work in this “The Web is going area 25 years ago seemed largely theo- Cloning retical, he is now finding practical ap- live,” says Ken plications for these approaches on the Web. “My theoretical work was ignited Birman. “This is Smart- by Leslie [Lamport],” he says. “Barba- going to change ra’s work brought me to look again at phones the practicality of the solutions.” the picture for At Microsoft, researcher Rama replication, creating A pair of scientists at Intel Kotla has proposed a new BFT replica- Research Berkeley have a demand from developed CloneCloud, which tion protocol known as Zyzzyva, that creates an identical clone of an strives to improve performance by us- average users.” individual’s smartphone that ing a technique called speculation to resides in a cloud-computing achieve low performance overheads. environment. Created by Intel researchers Kotla is also exploring a complemen- Byung-Gon Chun and Petros tary technique called high throughput Maniatis, CloneCloud uses BFT that exploits parallelism to im- a smartphone’s Internet connection to communicate prove the performance of a replicated cost of doing business on the Web.
Recommended publications
  • The Power of Abstraction
    The Power of Abstraction Barbara Liskov March 2013 MIT CSAIL Software is Complex Systems are big and they do complicated things and they may be distributed and/or concurrent Addressing Complexity Algorithms, data structures, protocols Addressing Complexity Algorithms, data structures, protocols Programming methodology Programming languages This Talk Programming methodology as it developed Programming languages Programming languages today The Situation in 1970 The software crisis! Programming Methodology How should programs be designed? How should programs be structured? The Landscape E. W. Dijkstra. Go To Statement Considered Harmful. Cacm, Mar. 1968 The Landscape N. Wirth. Program Development by Stepwise Refinement. Cacm, April 1971 The Landscape D. L. Parnas. Information Distribution Aspects of Design Methodology. IFIP Congress, 1971 “The connections between modules are the assumptions which the modules make about each other.” Modularity A program is a collection of modules Modularity A program is a collection of modules Each module has an interface, described by a specification Modularity A program is a collection of modules Each has an interface, described by a specification A module’s implementation is correct if it meets the specification A using module depends only on the specification Modularity A program is a collection of modules Each has an interface, described by a specification A module’s implementation is correct if it meets the specification A using module depends only on the specification E.g. a sort routine sort(a) Benefits of Modularity Local reasoning Modifiability Independent development The Situation in 1970 Procedures were the only type of module Not powerful enough, e.g., a file system Not used very much Complicated connections Partitions B.
    [Show full text]
  • MIT Turing Laureates Propose Creation of School of Computing an Open Letter to President Rafael Reif
    9/26/2017 The Tech OPINION LETTER TO THE EDITOR MIT Turing laureates propose creation of School of Computing An open letter to President Rafael Reif By MIT Turing Laureates | Sep. 20, 2017 Facebook Dear Rafael, Twitter There comes a time, in the course of scientic evolution, when a discipline is ready to emerge from the womb of its parent disciplines and take its own place in the world. For Reddit computer science, or more accurately, for the eld of computing, this moment is now. Print Born from a combination of mathematics and electrical engineering, with the original intent of speeding up calculations, computer science has grown to encompass all information processing and most communications and now to provide an alternative evolutionary path to intelligence. Computer science is rapidly becoming an essential part of most academic disciplines, and students are voting with their feet. One third of MIT undergraduates are majoring in computer science. This trend is unlikely to slow down anytime soon. We, the 7 active MIT Turing Award winners, therefore write this open letter to recommend that you consider the bold step of establishing a School of Computing at MIT. The new school, a brother to the Schools of Engineering and Science, will allow the eld of computing, with its many https://thetech.com/2017/09/20/turing-laureates-open-letter-to-reif 1/4 9/26/2017 The Tech facets and sub-elds, to grow and interact naturally with the Institute’s scientic and engineering environment. The Tech Submit Campus Life Stories Today the study of computation is housed primarily in the EECS department within the School of Engineering, but departments are limited in their ability to hire and grow.
    [Show full text]
  • On-The-Fly Garbage Collection: an Exercise in Cooperation
    8. HoIn, B.K.P. Determining lightness from an image. Comptr. Graphics and Image Processing 3, 4(Dec. 1974), 277-299. 9. Huffman, D.A. Impossible objects as nonsense sentences. In Machine Intelligence 6, B. Meltzer and D. Michie, Eds., Edinburgh U. Press, Edinburgh, 1971, pp. 295-323. 10. Mackworth, A.K. Consistency in networks of relations. Artif. Intell. 8, 1(1977), 99-118. I1. Marr, D. Simple memory: A theory for archicortex. Philos. Trans. Operating R.S. Gaines Roy. Soc. B. 252 (1971), 23-81. Systems Editor 12. Marr, D., and Poggio, T. Cooperative computation of stereo disparity. A.I. Memo 364, A.I. Lab., M.I.T., Cambridge, Mass., 1976. On-the-Fly Garbage 13. Minsky, M., and Papert, S. Perceptrons. M.I.T. Press, Cambridge, Mass., 1968. Collection: An Exercise in 14. Montanari, U. Networks of constraints: Fundamental properties and applications to picture processing. Inform. Sci. 7, 2(April 1974), Cooperation 95-132. 15. Rosenfeld, A., Hummel, R., and Zucker, S.W. Scene labelling by relaxation operations. IEEE Trans. Systems, Man, and Cybernetics Edsger W. Dijkstra SMC-6, 6(June 1976), 420-433. Burroughs Corporation 16. Sussman, G.J., and McDermott, D.V. From PLANNER to CONNIVER--a genetic approach. Proc. AFIPS 1972 FJCC, Vol. 41, AFIPS Press, Montvale, N.J., pp. 1171-1179. Leslie Lamport 17. Sussman, G.J., and Stallman, R.M. Forward reasoning and SRI International dependency-directed backtracking in a system for computer-aided circuit analysis. A.I. Memo 380, A.I. Lab., M.I.T., Cambridge, Mass., 1976. A.J. Martin, C.S.
    [Show full text]
  • Arxiv:1909.05204V3 [Cs.DC] 6 Feb 2020
    Cogsworth: Byzantine View Synchronization Oded Naor, Technion and Calibra Mathieu Baudet, Calibra Dahlia Malkhi, Calibra Alexander Spiegelman, VMware Research Most methods for Byzantine fault tolerance (BFT) in the partial synchrony setting divide the local state of the nodes into views, and the transition from one view to the next dictates a leader change. In order to provide liveness, all honest nodes need to stay in the same view for a sufficiently long time. This requires view synchronization, a requisite of BFT that we extract and formally define here. Existing approaches for Byzantine view synchronization incur quadratic communication (in n, the number of parties). A cascade of O(n) view changes may thus result in O(n3) communication complexity. This paper presents a new Byzantine view synchronization algorithm named Cogsworth, that has optimistically linear communication complexity and constant latency. Faced with benign failures, Cogsworth has expected linear communication and constant latency. The result here serves as an important step towards reaching solutions that have overall quadratic communication, the known lower bound on Byzantine fault tolerant consensus. Cogsworth is particularly useful for a family of BFT protocols that already exhibit linear communication under various circumstances, but suffer quadratic overhead due to view synchro- nization. 1. INTRODUCTION Logical synchronization is a requisite for progress to be made in asynchronous state machine repli- cation (SMR). Previous Byzantine fault tolerant (BFT) synchronization mechanisms incur quadratic message complexities, frequently dominating over the linear cost of the consensus cores of BFT so- lutions. In this work, we define the view synchronization problem and provide the first solution in the Byzantine setting, whose latency is bounded and communication cost is linear, under a broad set of scenarios.
    [Show full text]
  • Mathematical Writing by Donald E. Knuth, Tracy Larrabee, and Paul M
    Mathematical Writing by Donald E. Knuth, Tracy Larrabee, and Paul M. Roberts This report is based on a course of the same name given at Stanford University during autumn quarter, 1987. Here's the catalog description: CS 209. Mathematical Writing|Issues of technical writing and the ef- fective presentation of mathematics and computer science. Preparation of theses, papers, books, and \literate" computer programs. A term paper on a topic of your choice; this paper may be used for credit in another course. The first three lectures were a \minicourse" that summarized the basics. About two hundred people attended those three sessions, which were devoted primarily to a discussion of the points in x1 of this report. An exercise (x2) and a suggested solution (x3) were also part of the minicourse. The remaining 28 lectures covered these and other issues in depth. We saw many examples of \before" and \after" from manuscripts in progress. We learned how to avoid excessive subscripts and superscripts. We discussed the documentation of algorithms, com- puter programs, and user manuals. We considered the process of refereeing and editing. We studied how to make effective diagrams and tables, and how to find appropriate quota- tions to spice up a text. Some of the material duplicated some of what would be discussed in writing classes offered by the English department, but the vast majority of the lectures were devoted to issues that are specific to mathematics and/or computer science. Guest lectures by Herb Wilf (University of Pennsylvania), Jeff Ullman (Stanford), Leslie Lamport (Digital Equipment Corporation), Nils Nilsson (Stanford), Mary-Claire van Leunen (Digital Equipment Corporation), Rosalie Stemer (San Francisco Chronicle), and Paul Halmos (University of Santa Clara), were a special highlight as each of these outstanding authors presented their own perspectives on the problems of mathematical communication.
    [Show full text]
  • Verification and Specification of Concurrent Programs
    Verification and Specification of Concurrent Programs Leslie Lamport 16 November 1993 To appear in the proceedings of a REX Workshop held in The Netherlands in June, 1993. Verification and Specification of Concurrent Programs Leslie Lamport Digital Equipment Corporation Systems Research Center Abstract. I explore the history of, and lessons learned from, eighteen years of assertional methods for specifying and verifying concurrent pro- grams. I then propose a Utopian future in which mathematics prevails. Keywords. Assertional methods, fairness, formal methods, mathemat- ics, Owicki-Gries method, temporal logic, TLA. Table of Contents 1 A Brief and Rather Biased History of State-Based Methods for Verifying Concurrent Systems .................. 2 1.1 From Floyd to Owicki and Gries, and Beyond ........... 2 1.2Temporal Logic ............................ 4 1.3 Unity ................................. 5 2 An Even Briefer and More Biased History of State-Based Specification Methods for Concurrent Systems ......... 6 2.1 Axiomatic Specifications ....................... 6 2.2 Operational Specifications ...................... 7 2.3 Finite-State Methods ........................ 8 3 What We Have Learned ........................ 8 3.1 Not Sequential vs. Concurrent, but Functional vs. Reactive ... 8 3.2Invariance Under Stuttering ..................... 8 3.3 The Definitions of Safety and Liveness ............... 9 3.4 Fairness is Machine Closure ..................... 10 3.5 Hiding is Existential Quantification ................ 10 3.6 Specification Methods that Don’t Work .............. 11 3.7 Specification Methods that Work for the Wrong Reason ..... 12 4 Other Methods ............................. 14 5 A Brief Advertisement for My Approach to State-Based Ver- ification and Specification of Concurrent Systems ....... 16 5.1 The Power of Formal Mathematics ................. 16 5.2Specifying Programs with Mathematical Formulas ........ 17 5.3 TLA .................................
    [Show full text]
  • The Specification Language TLA+
    Leslie Lamport: The Speci¯cation Language TLA+ This is an addendum to a chapter by Stephan Merz in the book Logics of Speci¯cation Languages by Dines Bj¿rner and Martin C. Henson (Springer, 2008). It appeared in that book as part of a \reviews" chapter. Stephan Merz describes the TLA logic in great detail and provides about as good a description of TLA+ and how it can be used as is possible in a single chapter. Here, I give a historical account of how I developed TLA and TLA+ that explains some of the design choices, and I briefly discuss how TLA+ is used in practice. Whence TLA The logic TLA adds three things to the very simple temporal logic introduced into computer science by Pnueli [4]: ² Invariance under stuttering. ² Temporal existential quanti¯cation. ² Taking as atomic formulas not just state predicates but also action for- mulas. Here is what prompted these additions. When Pnueli ¯rst introduced temporal logic to computer science in the 1970s, it was clear to me that it provided the right logic for expressing the simple liveness properties of concurrent algorithms that were being considered at the time and for formalizing their proofs. In the early 1980s, interest turned from ad hoc properties of systems to complete speci¯cations. The idea of speci- fying a system as a conjunction of the temporal logic properties it should satisfy seemed quite attractive [5]. However, it soon became obvious that this approach does not work in practice. It is impossible to understand what a conjunction of individual properties actually speci¯es.
    [Show full text]
  • Using Lamport Clocks to Reason About Relaxed Memory Models
    Using Lamport Clocks to Reason About Relaxed Memory Models Anne E. Condon, Mark D. Hill, Manoj Plakal, Daniel J. Sorin Computer Sciences Department University of Wisconsin - Madison {condon,markhill,plakal,sorin}@cs.wisc.edu Abstract industrial product groups spend more time verifying their Cache coherence protocols of current shared-memory mul- system than actually designing and optimizing it. tiprocessors are difficult to verify. Our previous work pro- To verify a system, engineers should unambiguously posed an extension of Lamport’s logical clocks for showing define what “correct” means. For a shared-memory sys- that multiprocessors can implement sequential consistency tem, “correct” is defined by a memory consistency model. (SC) with an SGI Origin 2000-like directory protocol and a A memory consistency model defines for programmers the Sun Gigaplane-like split-transaction bus protocol. Many allowable behavior of hardware. A commonly-assumed commercial multiprocessors, however, implement more memory consistency model requires a shared-memory relaxed models, such as SPARC Total Store Order (TSO), a multiprocessor to appear to software as a multipro- variant of processor consistency, and Compaq (DEC) grammed uniprocessor. This model was formalized by Alpha, a variant of weak consistency. Lamport as sequential consistency (SC) [12]. Assume that This paper applies Lamport clocks to both a TSO and an each processor executes instructions and memory opera- Alpha implementation. Both implementations are based on tions in a dynamic execution order called program order. the same Sun Gigaplane-like split-transaction bus protocol An execution is SC if there exists a total order of memory we previously used, but the TSO implementation places a operations (reads and writes) in which (a) the program first-in-first-out write buffer between a processor and its orders of all processors are respected and (b) a read returns cache, while the Alpha implementation uses a coalescing the value of the last write (to the same address) in this write buffer.
    [Show full text]
  • Should Your Specification Language Be Typed?
    Should Your Specification Language Be Typed? LESLIE LAMPORT Compaq and LAWRENCE C. PAULSON University of Cambridge Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification lan- guage without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language. We consider only specification languages, not programming languages. Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements/Specifica- tions; D.2.4 [Software Engineering]: Software/Program Verification—formal methods; F.3.1 [Logics and Meanings of Programs]: Specifying and Verifying and Reasoning about Pro- grams—specification techniques General Terms: Verification Additional Key Words and Phrases: Set theory, specification, types Editors’ introduction. We have invited the following
    [Show full text]
  • (LA)TEX Changed the Face of Mathematics: An
    20 TUGboat, Volume 22 (2001), No. 1/2 How (LA)TEX changed the face of Mathematics: An E-interview with Leslie Lamport, the author of LATEX∗ A great deal of mathematics, including this journal, is typeset with TEX or LATEX; this has made a last- ing change on the face of (published) mathematics, and has also permanently revolutionized mathemat- ics publishing. Many mathematicians typeset their own mathematics with these systems, and this has also changed mathematical thinking, so that in a ca- sual√ conversation one might write \sqrt{2} instead of 2 on the tablecloth . We take “ca. 20 years of TEX” as the occasion to ask Leslie Lamport, the author of LATEX, some questions. (GMZ) LL: At the time, it never really occurred to me that − − ∗ − − people would pay money for software. I certainly GMZ: How were your own first papers produced? Did didn’t think that people would pay money for a you start out on a typewriter? On roff/troff/nroff? book about software. Fortunately, Peter Gordon A LL: Typically, when writing a paper, I would write at Addison-Wesley convinced me to turn the LTEX a first draft in pen, then go to typewritten drafts. I manual into a book. In retrospect, I think I made would edit each typed draft with pencil or pen until more money by giving the software away and selling it became unreadable, and would then type the next the book than I would have by trying to sell the A draft. I think I usually had two typewritten drafts. software.
    [Show full text]
  • A Fast Mutual Exclusion Algorithm
    A Fast Mutual Exclusion Algorithm LESLIE LAMPORT Digital Equipment Corporation A new solution to the mutual exclusion problem is presented that, in the absence of contention, requires only seven memory accesses. It assumes atomic reads and atomic writes to shared regis- ters. Categories and Subject Descriptors: D.4.1 [Operating Systems]: Process Management-rnuti mlti General terms: Algorithms Additional Key Words and Phrases: Critical section, multiprocessing I. INTRODUCTION The mutual exclusion problem-guaranteeing mutually exclusive access to a crit- ical section among a number of competing processes-is well known, and many solutions have been published. The original version of the problem, as presented by Dijkstra [2], assumed a shared memory with atomic read and write operations. Since the early 19709, solutions to this version have been of little practical interest. If the concurrent processesare being time-shared on a single processor, then mutual exclusion is easily achieved by inhibiting hardware interrupts at crucial times. On the other hand, multiprocessor computers have been built with atomic test-and- set instructions that permitted much simpler mutual exclusion algorithms. Since about 1974, researchers have concentrated on finding algorithms that use a more restricted form of shared memory or that use message passing instead of shared memory. Of late, the original version of the problem has not been widely studied. Recently, there has arisen interest in building shared-memory multiprocessor computers by connecting standard processors and memories, with as little modifica- tion to the hardware as possible. Because ordinary sequential processors and mem- ories do not have atomic test-and-set operations, it is worth investigating whether shared-memory mutual exclusion algorithms are a practical alternative.
    [Show full text]
  • The Greatest Pioneers in Computer Science
    The Greatest Pioneers in Computer Science Ivan Srba, Veronika Gondová 19th October 2017 5th Heidelberg Laureate Forum 2 Laureates of mathematics and computer science meet the next generation September 24–29, 2017, Heidelberg https://www.heidelberg-laureate-forum.org 3 Awards in Computer Science 4 Awards in Computer Science 5 • ACM A.M. Turing Award • “Nobel Prize of Computing” • Awarded to “an individual selected for contributions of a technical nature made to the computing community” • Accompanied by a prize of $1 million Awards in Computer Science 6 • ACM A.M. Turing Award • “Nobel Prize of Computing” • Awarded to “an individual selected for contributions of a technical nature made to the computing community” • Accompanied by a prize of $1 million • ACM Prize in Computing • Awarded to “an early to mid-career fundamental innovative contribution in computing” • Accompanied by a prize of $250,000 Some of Laureates We Met at 5th HLF 7 PeWe Postcard 8 Leslie Lamport 9 ACM A.M. Turing Award (2013) Source: https://www.heidelberg-laureate-forum.org/blog/laureate/leslie-lamport/ Leslie Lamport 10 ACM A.M. Turing Award (2013) “for fundamental contributions to the theory and practice of distributed and concurrent systems, notably the invention of concepts such as causality and logical clocks, safety and liveness, replicated state machines, and sequential consistency.” • Developed Lamport Clocks for distributed systems • The paper “Time, Clocks, and the Ordering of Events in a Distributed System” from 1978 has become one of the most cited works in computer science • Developed LaTeX • Invented the first digital signature algorithm • Currently work in Microsoft Research Source: https://www.heidelberg-laureate-forum.org/blog/laureate/leslie-lamport/ Balmer’s Peak 11 • The theory that computer programmers obtain quasi-magical, superhuman coding ability • when they have a blood alcohol concentration percentage between 0.129% and 0.138%.
    [Show full text]