Download Slides

Total Page:16

File Type:pdf, Size:1020Kb

Download Slides Rediscovering Distributed Systems Steve Vinoski Basho Technologies Cambridge, MA USA http://basho.com @stevevinoski [email protected] http://steve.vinoski.net/ Thursday, October 17, 13 1 Distributed Systems are Everywhere Thursday, October 17, 13 2 Distributed Systems are Difficult Thursday, October 17, 13 3 On The Shoulders of Giants • "Distributed systems" describes an enormous history of research and practice • Dist Sys research/practice addresses many issues from many angles • Know the issues so you can choose the right trade-offs Thursday, October 17, 13 4 Scope • Way way too much to cover • This talk is based in part on my personal history and experiences • Others would give a completely different talk Thursday, October 17, 13 5 1960s Thursday, October 17, 13 6 1960s • Beginnings of concurrent systems • 1965: Dijkstra's semaphores • Beginnings of computer networking • J.C.R. Licklider's 1962 dream of an "Intergalactic Computer Network" would eventually lead to the Internet • Beginning of OO: Simula 67 Thursday, October 17, 13 7 Distributed Systems Failure • 1965 Northeast blackout affected 7 US states and Ontario • A single misconfigured relay caused massive cascading failures • Then and now: distributed systems failure is not uncommon Thursday, October 17, 13 8 Dijkstra and Multiprogramming • 1968: "The Structure of the 'THE' Multiprogramming System" • Describes a whole system designed as a set of hierarchical cooperating sequential processes • System resources shared via mutual synchronization via semaphores Thursday, October 17, 13 9 Dijkstra and Multiprogramming "At the time this was written the testing had not yet been completed, but the resulting system is guaranteed to be flawless." —E.W. Dijkstra "The Structure of the 'THE' Multiprogramming System" Thursday, October 17, 13 10 1970s Thursday, October 17, 13 11 1970s Issues • Interprocess Communication • Resource sharing • Programming languages and distributed computing • Application-to-application protocols Thursday, October 17, 13 12 Interprocess Communication (IPC) • "Interprocess Communication Facilities for Network Operating Systems", Akkoyunlu, Bernstein, Schantz, 1974 • Discusses IPC over different network topologies • Compares connection-oriented and message- oriented IPC facilities • Discusses concerns of how sender and receiver might find and identify each other Thursday, October 17, 13 13 IPC Thursday, October 17, 13 14 IPC Thursday, October 17, 13 15 Thursday, October 17, 13 16 Resource Sharing "Users and administrators of a small computer often desire more service than it can provide. In a network environment additional services can be provided to the small computer, and in turn to the users of the small computer, by one or more other computers." —Akkoyunlu, Bernstein, Schantz "Interprocess Communication Facilities for Network Operating Systems" Thursday, October 17, 13 17 Resource Sharing • "An Operational System for Computer Resource Sharing", Cosell et al., 1975 • Ideas like today's cloud computing Thursday, October 17, 13 18 Resource Sharing "Further , it was becoming clear that for many users, in particular those whose access to the network was via TIPs or other non- TENEX hosts, it should not actually matter which host provides the TENEX service so long as the users could do their computing in the manner to which they had become accustomed." —Cosell et al. "An Operational System for Computer Resource Sharing" Thursday, October 17, 13 19 Resource Sharing "A number of advantages would result from such resource sharing. The user would see TENEX as a much more accessible and reliable resource. Because he would no longer be dependent upon a single host for his computing, he would be able to access the TENEX virtual machine even when one or more of the TENEX hosts were unavailable." —Cosell et al. "An Operational System for Computer Resource Sharing" Thursday, October 17, 13 20 Distributed Processing, January 1978 Thursday, October 17, 13 21 Distributed Processing, January 1978 "A terminal with a resident text editor, whether it is provided by hardware or software, is not an example of a distributed data processing system." "If the terminal coordinates several concurrent and simultaneous remote jobs, giving each a different type of service at a different location, without human intervention, then it more closely resembles a distributed system." —P.H. Enslow, Jr. "What is a 'Distributed' Data Processing System?" Thursday, October 17, 13 22 1978: Issues in Distributed Processing "Participants generally agreed that distributed processing is made possible by the price-performance revolution in microelectronics." —Eckhouse and Stankovic "Issues in Distributed Processing - An Overview of Two Workshops" Thursday, October 17, 13 23 1978: Issues in Distributed Processing • IPC • Distributed operating systems • Distributed databases • Load balancing Thursday, October 17, 13 24 State Machines "A distributed system can be described as a particular sequential state machine that is implemented with a network of processors." Leslie Lamport http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#time-clocks Thursday, October 17, 13 25 Ordering of Events • "Time, Clocks, and the Ordering of Events in a Distributed System", L. Lamport, 1978 • Probably the most cited Dist Sys paper ever Thursday, October 17, 13 26 Ordering of Events • event A happens before event B if • A occurs before B in the same process • or A is a send of M from process P1, and B is the receive of M in process P2 • happens-before is written as A → B • if A → B and B → C, then A → C Thursday, October 17, 13 27 Ordering of Events • Clock Condition: • if A → B then LogicalClock(A) < LogicalClock(B) Thursday, October 17, 13 28 Ordering of Events e11 P1 1 t e21 P2 1 t e31 P3 1 t Thursday, October 17, 13 29 Ordering of Events e11 e12 P1 1 2 t e21 e22 P2 1 3 t e31 e32 P3 1 2 t Thursday, October 17, 13 30 Ordering of Events e11 e12 e13 e14 P1 1 2 3 5 t e21 e22 e23 e24 P2 1 3 4 5 t e31 e32 e33 e34 P3 1 2 3 4 t Only partial ordering, since e.g. e32 ↛ e14 Thursday, October 17, 13 31 Ordering of Events • Total ordering achieved by choosing an arbitrary ordering for processes • A ⇒ B iff • C(A) < C(B) • or, C(A) == C(B) and Pa < Pb • Remainder of paper shows how it all works with physical clocks Thursday, October 17, 13 32 Languages and Distributed Systems • Handling concurrency in programming languages • Handling distribution in programming languages • What are the best primitives in such languages? Thursday, October 17, 13 33 Communicating Sequential Processes • "Communicating Sequential Processes", Tony Hoare, 1978 • Defines "surprisingly versatile" primitives for structuring concurrent programs Thursday, October 17, 13 34 Communicating Sequential Processes • Dijkstra's guarded commands for sequential control structures • Dijkstra's parbegin to specify concurrent execution • Input and output commands to allow processes to communicate • Input commands in guards • Pattern matching on input messages Thursday, October 17, 13 35 Communicating Sequential Processes • The paper then uses these primitives to show solutions to a variety of programming problems Thursday, October 17, 13 36 Primitives for Distributed Computing • "Primitives for Distributed Computing", Barbara Liskov, 1979 • Describes distributed computing primitives, focusing on modularity and communication Thursday, October 17, 13 37 Primitives for Distributed Computing • Reasons for distributed computing: • To match distributed organizations • Reduced contention among organization divisions • Speed of access • Physical control • Better availability, reliability, extensibility • But at the time there was little experience in building distributed programs Thursday, October 17, 13 38 Primitives for Distributed Computing • Approach: extend the CLU language with distributed computing primitives • CLU supported data abstractions and objects Structured programming CLU ⇒ + Modularity Data abstraction Thursday, October 17, 13 39 Modularity • Guardian: a collection of processes and objects that provides a distributed service • Processes in same guardian share objects • Processes in different guardians communicate only via messages • Each guardian bound to a single node • Each node can host multiple guardians Thursday, October 17, 13 40 Communication • No-wait send • Receive with timeout • Messages are commands with zero or more arguments • Messages are sent to ports • Ports are named and typed, defining the messages they accept • Guardians have one or more ports Thursday, October 17, 13 41 Primitives for Distributed Computing • Paper finishes by showing an example of a transactional airline reservation system • One conclusion: more experience with distributed programming needed Thursday, October 17, 13 42 App-to-App Protocols • ARPANET, forerunner of the Internet, started operating in late 1969 • Early host-to-host protocols facilitated human-to-computer communications • Email in 1971 • FTP and interoperable Telnet in 1973 • Interest started growing in application-to- application protocols Thursday, October 17, 13 43 RFC 707 • J. E. White, RFC 707, “A High-Level Framework for Network-Based Resource Sharing, 1975 • Expressed concerns that programmers • didn't know how to write distributed applications • but did know how to write libraries • so, why not make distributed programming look just like library programming? Thursday, October 17, 13 44 RFC 674 and 707 • RFCs 674 and 707 basically define what would become the remote procedure call (RPC) • But
Recommended publications
  • ACM SIGACT News Distributed Computing Column 28
    ACM SIGACT News Distributed Computing Column 28 Idit Keidar Dept. of Electrical Engineering, Technion Haifa, 32000, Israel [email protected] Sergio Rajsbaum, who edited this column for seven years and established it as a relevant and popular venue, is stepping down. This issue is my first step in the big shoes he vacated. I would like to take this opportunity to thank Sergio for providing us with seven years’ worth of interesting columns. In producing these columns, Sergio has enjoyed the support of the community at-large and obtained material from many authors, who greatly contributed to the column’s success. I hope to enjoy a similar level of support; I warmly welcome your feedback and suggestions for material to include in this column! The main two conferences in the area of principles of distributed computing, PODC and DISC, took place this summer. This issue is centered around these conferences, and more broadly, distributed computing research as reflected therein, ranging from reviews of this year’s instantiations, through influential papers in past instantiations, to examining PODC’s place within the realm of computer science. I begin with a short review of PODC’07, and highlight some “hot” trends that have taken root in PODC, as reflected in this year’s program. Some of the forthcoming columns will be dedicated to these up-and- coming research topics. This is followed by a review of this year’s DISC, by Edward (Eddie) Bortnikov. For some perspective on long-running trends in the field, I next include the announcement of this year’s Edsger W.
    [Show full text]
  • Edsger Dijkstra: the Man Who Carried Computer Science on His Shoulders
    INFERENCE / Vol. 5, No. 3 Edsger Dijkstra The Man Who Carried Computer Science on His Shoulders Krzysztof Apt s it turned out, the train I had taken from dsger dijkstra was born in Rotterdam in 1930. Nijmegen to Eindhoven arrived late. To make He described his father, at one time the president matters worse, I was then unable to find the right of the Dutch Chemical Society, as “an excellent Aoffice in the university building. When I eventually arrived Echemist,” and his mother as “a brilliant mathematician for my appointment, I was more than half an hour behind who had no job.”1 In 1948, Dijkstra achieved remarkable schedule. The professor completely ignored my profuse results when he completed secondary school at the famous apologies and proceeded to take a full hour for the meet- Erasmiaans Gymnasium in Rotterdam. His school diploma ing. It was the first time I met Edsger Wybe Dijkstra. shows that he earned the highest possible grade in no less At the time of our meeting in 1975, Dijkstra was 45 than six out of thirteen subjects. He then enrolled at the years old. The most prestigious award in computer sci- University of Leiden to study physics. ence, the ACM Turing Award, had been conferred on In September 1951, Dijkstra’s father suggested he attend him three years earlier. Almost twenty years his junior, I a three-week course on programming in Cambridge. It knew very little about the field—I had only learned what turned out to be an idea with far-reaching consequences. a flowchart was a couple of weeks earlier.
    [Show full text]
  • Arxiv:1901.04709V1 [Cs.GT]
    Self-Stabilization Through the Lens of Game Theory Krzysztof R. Apt1,2 and Ehsan Shoja3 1 CWI, Amsterdam, The Netherlands 2 MIMUW, University of Warsaw, Warsaw, Poland 3 Sharif University of Technology, Tehran, Iran Abstract. In 1974 E.W. Dijkstra introduced the seminal concept of self- stabilization that turned out to be one of the main approaches to fault- tolerant computing. We show here how his three solutions can be for- malized and reasoned about using the concepts of game theory. We also determine the precise number of steps needed to reach self-stabilization in his first solution. 1 Introduction In 1974 Edsger W. Dijkstra introduced in a two-page article [10] the notion of self-stabilization. The paper was completely ignored until 1983, when Leslie Lamport stressed its importance in his invited talk at the ACM Symposium on Principles of Distributed Computing (PODC), published a year later as [21]. Things have changed since then. According to Google Scholar Dijkstra’s paper has been by now cited more than 2300 times. It became one of the main ap- proaches to fault tolerant computing. An early survey was published in 1993 as [26], while the research on the subject until 2000 was summarized in the book [13]. In 2002 Dijkstra’s paper won the PODC influential paper award (renamed in 2003 to Dijkstra Prize). The literature on the subject initiated by it continues to grow. There are annual Self-Stabilizing Systems Workshops, the 18th edition of which took part in 2016. The idea proposed by Dijkstra is very simple. Consider a distributed system arXiv:1901.04709v1 [cs.GT] 15 Jan 2019 viewed as a network of machines.
    [Show full text]
  • Distributed Algorithms for Wireless Networks
    A THEORETICAL VIEW OF DISTRIBUTED SYSTEMS Nancy Lynch, MIT EECS, CSAIL National Science Foundation, April 1, 2021 Theory for Distributed Systems • We have worked on theory for distributed systems, trying to understand (mathematically) their capabilities and limitations. • This has included: • Defining abstract, mathematical models for problems solved by distributed systems, and for the algorithms used to solve them. • Developing new algorithms. • Producing rigorous proofs, of correctness, performance, fault-tolerance. • Proving impossibility results and lower bounds, expressing inherent limitations of distributed systems for solving problems. • Developing foundations for modeling, analyzing distributed systems. • Kinds of systems: • Distributed data-management systems. • Wired, wireless communication systems. • Biological systems: Insect colonies, developmental biology, brains. This talk: 1. Algorithms for Traditional Distributed Systems 2. Impossibility Results 3. Foundations 4. Algorithms for New Distributed Systems 1. Algorithms for Traditional Distributed Systems • Mutual exclusion in shared-memory systems, resource allocation: Fischer, Burns,…late 70s and early 80s. • Dolev, Lynch, Pinter, Stark, Weihl. Reaching approximate agreement in the presence of faults. JACM,1986. • Lundelius, Lynch. A new fault-tolerant algorithm for clock synchronization. Information and Computation,1988. • Dwork, Lynch, Stockmeyer. Consensus in the presence of partial synchrony. JACM,1988. Dijkstra Prize, 2007. 1A. Dwork, Lynch, Stockmeyer [DLS] “This paper introduces a number of practically motivated partial synchrony models that lie between the completely synchronous and the completely asynchronous models and in which consensus is solvable. It gave practitioners the right tool for building fault-tolerant systems and contributed to the understanding that safety can be maintained at all times, despite the impossibility of consensus, and progress is facilitated during periods of stability.
    [Show full text]
  • 2020 SIGACT REPORT SIGACT EC – Eric Allender, Shuchi Chawla, Nicole Immorlica, Samir Khuller (Chair), Bobby Kleinberg September 14Th, 2020
    2020 SIGACT REPORT SIGACT EC – Eric Allender, Shuchi Chawla, Nicole Immorlica, Samir Khuller (chair), Bobby Kleinberg September 14th, 2020 SIGACT Mission Statement: The primary mission of ACM SIGACT (Association for Computing Machinery Special Interest Group on Algorithms and Computation Theory) is to foster and promote the discovery and dissemination of high quality research in the domain of theoretical computer science. The field of theoretical computer science is the rigorous study of all computational phenomena - natural, artificial or man-made. This includes the diverse areas of algorithms, data structures, complexity theory, distributed computation, parallel computation, VLSI, machine learning, computational biology, computational geometry, information theory, cryptography, quantum computation, computational number theory and algebra, program semantics and verification, automata theory, and the study of randomness. Work in this field is often distinguished by its emphasis on mathematical technique and rigor. 1. Awards ▪ 2020 Gödel Prize: This was awarded to Robin A. Moser and Gábor Tardos for their paper “A constructive proof of the general Lovász Local Lemma”, Journal of the ACM, Vol 57 (2), 2010. The Lovász Local Lemma (LLL) is a fundamental tool of the probabilistic method. It enables one to show the existence of certain objects even though they occur with exponentially small probability. The original proof was not algorithmic, and subsequent algorithmic versions had significant losses in parameters. This paper provides a simple, powerful algorithmic paradigm that converts almost all known applications of the LLL into randomized algorithms matching the bounds of the existence proof. The paper further gives a derandomized algorithm, a parallel algorithm, and an extension to the “lopsided” LLL.
    [Show full text]
  • LNCS 4308, Pp
    On Distributed Verification Amos Korman and Shay Kutten Faculty of IE&M, Technion, Haifa 32000, Israel Abstract. This paper describes the invited talk given at the 8th Inter- national Conference on Distributed Computing and Networking (ICDCN 2006), at the Indian Institute of Technology Guwahati, India. This talk was intended to give a partial survey and to motivate further studies of distributed verification. To serve the purpose of motivating, we allow ourselves to speculate freely on the potential impact of such research. In the context of sequential computing, it is common to assume that the task of verifying a property of an object may be much easier than computing it (consider, for example, solving an NP-Complete problem versus verifying a witness). Extrapolating from the impact the separation of these two notions (computing and verifying) had in the context of se- quential computing, the separation may prove to have a profound impact on the field of distributed computing as well. In addition, in the context of distributed computing, the motivation for the separation seems even stronger than in the centralized sequential case. In this paper we explain some motivations for specific definitions, sur- vey some very related notions and their motivations in the literature, survey some examples for problems and solutions, and mention some ad- ditional general results such as general algorithmic methods and general lower bounds. Since this paper is mostly intended to “give a taste” rather than be a comprehensive survey, we apologize to authors of additional related papers that we did not mention or detailed. 1 Introduction This paper addresses the problem of locally verifying global properties.
    [Show full text]
  • Stabilization
    Chapter 13 Stabilization A large branch of research in distributed computing deals with fault-tolerance. Being able to tolerate a considerable fraction of failing or even maliciously be- having (\Byzantine") nodes while trying to reach consensus (on e.g. the output of a function) among the nodes that work properly is crucial for building reli- able systems. However, consensus protocols require that a majority of the nodes remains non-faulty all the time. Can we design a distributed system that survives transient (short-lived) failures, even if all nodes are temporarily failing? In other words, can we build a distributed system that repairs itself ? 13.1 Self-Stabilization Definition 13.1 (Self-Stabilization). A distributed system is self-stabilizing if, starting from an arbitrary state, it is guaranteed to converge to a legitimate state. If the system is in a legitimate state, it is guaranteed to remain there, provided that no further faults happen. A state is legitimate if the state satisfies the specifications of the distributed system. Remarks: • What kind of transient failures can we tolerate? An adversary can crash nodes, or make nodes behave Byzantine. Indeed, temporarily an adversary can do harm in even worse ways, e.g. by corrupting the volatile memory of a node (without the node noticing { not unlike the movie Memento), or by corrupting messages on the fly (without anybody noticing). However, as all failures are transient, eventually all nodes must work correctly again, that is, crashed nodes get res- urrected, Byzantine nodes stop being malicious, messages are being delivered reliably, and the memory of the nodes is secure.
    [Show full text]
  • Download Distributed Systems Free Ebook
    DISTRIBUTED SYSTEMS DOWNLOAD FREE BOOK Maarten van Steen, Andrew S Tanenbaum | 596 pages | 01 Feb 2017 | Createspace Independent Publishing Platform | 9781543057386 | English | United States Distributed Systems - The Complete Guide The hope is that together, the system can maximize resources and information while preventing failures, as if one system fails, it won't affect the availability of the service. Banker's algorithm Dijkstra's algorithm DJP algorithm Prim's algorithm Dijkstra-Scholten algorithm Dekker's algorithm generalization Smoothsort Shunting-yard algorithm Distributed Systems marking algorithm Concurrent algorithms Distributed Systems algorithms Deadlock prevention algorithms Mutual exclusion algorithms Self-stabilizing Distributed Systems. Learn to code for free. For the first time computers would be able to send messages to other systems with a local IP address. The messages passed between machines contain forms of data that the systems want to share like databases, objects, and Distributed Systems. Also known as distributed computing and distributed databases, a distributed system is a collection of independent components located on different machines that share messages with each other in order to achieve common goals. To prevent infinite loops, running the code requires some amount of Ether. As mentioned in many places, one of which this great articleyou cannot have consistency and availability without partition tolerance. Because it works in batches jobs a problem arises where if your job fails — Distributed Systems need to restart the whole thing. While in a voting system an attacker need only add nodes to the network which is Distributed Systems, as free access to the network is a design targetin a CPU power based scheme an attacker faces a physical limitation: getting access to more and more powerful hardware.
    [Show full text]
  • Distributed Computing Column 36 Distributed Computing: 2009 Edition
    Distributed Computing Column 36 Distributed Computing: 2009 Edition Idit Keidar Dept. of Electrical Engineering, Technion Haifa, 32000, Israel [email protected] It’s now the season for colorful reviews of 2009. While you can read elsewhere about the year in sports, top-40 pop hit charts, people of the year, and so on, I throw my share into the mix with a (biased) review of this year’s major distributed computing events. Awards First, let’s look at awards. This year we learned that two women were recognized with ACM and IEEE prestigious awards for their achievements in, (among other things), distributed computing. Barbara Liskov won the 2008 ACM Turing Award for a range of contributions to practical and theoretical foundations of programming language and system design, some of which are in distributed computing. The award citation mentions her impact on distributed programming, decentralized information flow, replicated storage, and modular upgrading of distributed systems. I include below a short reflection, by Rodrigo Rodrigues, on Barbara Liskov’s Turing Award and legacy. Looking ahead to 2010, it was recently announced that Nancy Lynch is the recipient of the prestigious 2010 IEEE Emanuel R. Piore Award1 for her contributions to foundations of distributed and concurrent computing. The award is given for outstanding contributions in the field of information processing in relation to computer science. Leslie Lamport has won the same award in 2004 for his seminal contributions to the theory and practice of concurrent programming and fault-tolerant computing. The 2009 Edsger W. Dijkstra Prize in Distributed Computing was awarded to Joseph Halpern and Yoram Moses for “Knowledge and Common Knowledge in a Distributed Environment”.
    [Show full text]
  • 2011 Edsger W. Dijkstra Prize in Distributed Computing
    2011 Edsger W. Dijkstra Prize in Distributed Computing We are proud to announce that the 2011 Edsger W. Dijkstra Prize in Distributed Computing is awarded to Hagit Attiya, Amotz Bar-Noy, and Danny Dolev, for their paper Sharing Memory Robustly in Message-Passing Systems which appeared in the Journal of the ACM (JACM) 42(1):124-142 (1995). This fundamental paper presents the first asynchronous fault-tolerant simulation of shared memory in a message passing system. In 1985 Fischer, Lynch, and Paterson (FLP) proved that consensus is not attainable in asynchronous message passing systems with failures. In the following years, Loui and Abu-Amara, and Herlihy proved that solving consensus in an asynchronous shared memory system is harder than implementing a read/write register. However, it was not known whether read/ write registers are implementable in asynchronous message-passing systems with failures. Hagit Attiya, Amotz Bar-Noy, and Danny Dolev’s paper (ABD) answered this fundamental question afrmatively. The ABD paper makes an important foundational contribution by allowing one to “view the shared-memory model as a higher-level language for designing algorithms in asynchronous distributed systems.” In a manner similar to that in which Turing Machines were proved equivalent to Random Access Memory, ABD proved that the implications of FLP are not idiosyncratic to a particular model. Impossibility results and lower bounds can be proved in the higher-level shared memory model, and then automatically translated to message passing. Besides FLP, this includes results such as the impossibility of k-set agreement in asynchronous systems as well as various weakest failure detector constructions.
    [Show full text]
  • CHABBI-DOCUMENT-2015.Pdf
    ABSTRACT Software Support for Efficient Use of Modern Computer Architectures by Milind Chabbi Parallelism is ubiquitous in modern computer architectures. Heterogeneity of CPU cores and deep memory hierarchies make modern architectures difficult to program efficiently. Achieving top performance on supercomputers is difficult due to complex hardware, software, and their interactions. Production software systems fail to achieve top performance on modern architectures broadly due to three main causes: resource idleness, parallel overhead,anddata movement overhead.Thisdissertationpresentsnovelande↵ectiveperformance analysis tools, adap- tive runtime systems,andarchitecture-aware algorithms to understand and address these problems. Many future high performance systems will employ traditional multicore CPUs aug- mented with accelerators such as GPUs. One of the biggest concerns for accelerated systems is how to make best use of both CPU and GPU resources. Resource idleness arises in a parallel program due to insufficient parallelism and load imbalance, among other causes. To assess systemic resource idleness arising in GPU-accelerated architectures, we developed efficient profiling and tracing capabilities. We introduce CPU-GPU blame shifting—a novel technique to pinpoint and quantify the causes of resource idleness in GPU-accelerated archi- tectures. Parallel overheads arise due to synchronization constructs such as barriers and locks used in parallel programs. We developed a new technique to identify and eliminate redundant barriers at runtime in Partitioned Global Address Space programs. In addition, we developed a set of novel mutual exclusion algorithms that exploit locality in the memory hierarchy to improve performance on Non-Uniform Memory Access architectures. In modern architectures, inefficient or unnecessary memory accesses can severely degrade program performance.
    [Show full text]
  • Distributed Computing Column Maurice Herlihy’S 60Th Birthday Celebration
    Distributed Computing Column Maurice Herlihy’s 60th Birthday Celebration Panagiota Fatourou FORTH ICS & University of Crete [email protected] Maurice Herlihy is one of the most renowned members of the Distributed Computing community. He is currently a professor in the Computer Science De- partment at Brown University. He has an A.B. in Mathematics from Harvard Uni- versity, and a Ph.D. in Computer Science from M.I.T. He has served on the fac- ulty of Carnegie Mellon University and on the staff of DEC Cambridge Research Lab. He is the recipient of the 2003 Dijkstra Prize in Distributed Computing, the 2004 Gödel Prize in theoretical computer science, the 2008 ISCA influential pa- per award, the 2012 Edsger W. Dijkstra Prize, and the 2013 Wallace McDowell award. He received a 2012 Fullbright Distinguished Chair in the Natural Sciences and Engineering Lecturing Fellowship, and he is a fellow of the ACM, a fellow of the National Academy of Inventors, and a member of the National Academy of Engineering and the American Academy of Arts and Sciences. On the occasion of his 60th birthday, the SIGACT-SIGOPS Symposium on Principles of Distributed Computing (PODC), which was held in Paris, France in July 2014, hosted a celebration which included several technical presentations about Maurice’s work by colleagues and friends. This column includes a summary of some of these presentations, written by the speakers themselves. In the first arti- cle, Vassos Hadzilacos overviews and highlights the impact of Maurice’s seminal paper on wait-free synchronization. Then, Tim Harris provides a perspective on hardware trends and their impact on distributed computing, mentioning several interesting open problems and making connections to Maurice’s work.
    [Show full text]