DOCSLIB.ORG

Concurrent Programming: Algorithms, Principles, PART 1: Lock-Based Synchronization and Foundations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Motivation Synchronization is Coming Back • Synchonization is coming back, but is it the same? But is it the Same? • Lots of new concepts and mechanisms since locks! Michel RAYNAL [email protected] • The multicore (r)evolution The synchronization world has changed Institut Universitaire de France • IRISA, Universit´ede Rennes, France Dpt of Computing, Polytechnic Univ., Hong Kong c Michel Raynal Synchronization is coming back! 1 c Michel Raynal Synchronization is coming back! 2 A recent book on the topic Part I Concurrent programming: Algorithms, Principles, PART 1: Lock-Based Synchronization and Foundations • Chapter 1: The Mutual Exclusion Problem by Michel Raynal • Chapter 2: Solving Exclusion Problem Springer, 515 pages, 2013 • Chapter 3: Lock-Based Concurrent Objects ISBN: 978-3-642-32026-2 6 Parts, composed of 17 Chapters Balance: algorithms vs foundations c Michel Raynal Synchronization is coming back! 3 c Michel Raynal Synchronization is coming back! 4 Part II Part III PART 3: Mutex-free Synchronization Chapter 5: Mutex-Free Concurrent Objects PART 2: On the Foundations Side: the Atomicity Concept • • Chapter 6: Hybrid Concurrent Objects • Chapter 4: • Chapter 7: Wait-Free Objects from Read/write Registers Only Atomicity: Formal Definition and Properties • Chapter 8: Snapshot Objects from Read/Write Registers Only • Chapter 9: Renaming Objects from Read/Write Registers Only c Michel Raynal Synchronization is coming back! 5 c Michel Raynal Synchronization is coming back! 6 Part IV Part V PART 5: On the Foundations Side: from Safe Bits to Atomic Registers PART 4: The Transactional Memory Approach • Chapter 11: Safe, Regular, and Atomic Read/Write Registers • Chapter 10: Transactional Memory • Chapter 12: From Safe Bits to Atomic Bits: a Lower Bound and an Optimal Construction • Chapter 13: Bounded Constructions of Atomic b-Valued Registers c Michel Raynal Synchronization is coming back! 7 c Michel Raynal Synchronization is coming back! 8 Part V Summary Computing Model: Processes and Concurrent Objects PART 6: On the Foundations Side: • the Computability Power of Concurrent Objects • Base read/write model, more powerful models • On the safety side: Linearizability • Chapter 14: Universality of Consensus • On the liveness side: Progress conditions • Chapter 15: The Case of Unreliable Base Objects • Mutex-free concurrent objects • Chapter 16: • Comuptability power, consensus number, etc. Consensus Numbers and the Consensus Hierarchy • Hybrid concurrent objects • Chapter 17: The Alpha(s) and Omega of Consensus • Conclusion c Michel Raynal Synchronization is coming back! 9 c Michel Raynal Synchronization is coming back! 10 Part I Asynchronous process model (1) • Computing model: n sequential processes Π = p1,...,pn (Turing machines) • Timing model: Asynchrony: No upper bound on the MODEL and DEFINITIONS time required to execute a computation step • Failure model ⋆ No failure ⋆ Crash failure c Michel Raynal Synchronization is coming back! 11 c Michel Raynal Synchronization is coming back! 12 Asynchronous process model (2) Asynchronous Base Communication Model (1) Shared memory provides processes with • Process crash: a process behaves according to its spec- ification until it possibly crashes, i.e., halts prematurely • Reliable Read/Write atomic registers (after it has crashed a process is definitely stopped) • Reliable Compare&Swap atomic registers • Terminology wrt a run: • Atomic means that: ⋆ A Correct process is a p that never crashes i ⋆ The operations on a register appear as if they have been executed sequentially ⋆ A Faulty process is a pi that crashes ⋆ Each operation appears as being executed instanta- neously at some point of the time line between its start event and its end event c Michel Raynal Synchronization is coming back! 13 c Michel Raynal Synchronization is coming back! 14 Atomic register Other base (hardware) operations READ: 2 READ: 1 WRITE: 1 WRITE: 2 READ: 2 WRITE: 3 • Test&set • Fetch&add Real time line • Compare&swap Valueis1 3 2 • LL/SC • Swap, Mem-to-Mem SWAP - Lamport L., On interprocess Communication (part 1: Basic Formalism, Part 2: • etc. Algorithms), Distributed Computing, 1(2):77-101, 1986 - Herlihy M.P. and Wing J.L., Linearizability: a Correctness Condition for Concurrent Objects. ACM Trans. on Programming Languages and Systems, 12(3):463-492, 1990 c Michel Raynal Synchronization is coming back! 15 c Michel Raynal Synchronization is coming back! 16 Structural view (Base level) Part II p1 local memory pi local memory pn local memory p1 pi pn On the SAFETY side Asynchronous shared memory Abstraction (could be shared disks, SAN) c Michel Raynal Synchronization is coming back! 17 c Michel Raynal Synchronization is coming back! 18 SAFETY PROPERTY Concurrent Object: example An object accessed by concurrent processes p LINEARIZABILITY p1 pi n - Herlihy M.P. and Wing J.M., Linearizability: a correctness condition for concurrent objects. ACM Toplas, 12(3):463- 492, 1990 Enqueue (v) r ← Dequeue () - Lamport L., On interprocess Communication (part 1: Basic Formalism, Part 2: Algorithms), Distributed Com- puting, 1(2):77-101, 1986 c Michel Raynal Synchronization is coming back! 19 c Michel Raynal Synchronization is coming back! 20 Sequential vs Concurrent (1) History (Run, Execution) Enq (a) Enq (b) Deq (a|b|c) ? SEQUENTIAL: p1 Enq (a) Enq (c) Enq (b) Deq(a) Deq (c) Enq (c) Deq(a|b|c) ? p2 CONCURRENT: Enq (a) Enq (b) Deq (a|b|c) ? p1 History H Inv (Enq(b)) Sequences of events Res (Enq(b)) Enq (c) Deq(a|b|c) ? p2 A history defines a partial order on the operations c Michel Raynal Synchronization is coming back! 21 c Michel Raynal Synchronization is coming back! 22 Two types of Concurrent Objects Example: Interactive consistency • A concurrent object encapsulates a particular synchro problem Each process pi proposes a value vi • Concurrent objects with a sequential specification Queue, file, graph, tree, stack, ... and has to decide a value such that: ⋆ Fifo queue: producer/consumer problem • Validity. Let D[1..n] be the vector decided by a process. ⋆ File (register): Readers/writers problem ∀i ∈ [1..n]: D[i] ∈ {vi, ⊥} and D[i]= vi if pi is correct • Concurrent objects with a not-sequential specification • Agreement. No two processes decide different vectors Rendezvous Object, Interactive Consistency, • Termination. Every correct process decides Non Blocking Atomic Commit Object, ... c Michel Raynal Synchronization is coming back! 23 c Michel Raynal Synchronization is coming back! 24 Linearizability Sequential vs Concurrent (2) Enq (a) Enq (b) Deq (a|b|c) ? An execution (or “history”) H is linearizable if the opera- p1 tions issued by the processes appear as if they have been executed in some sequential order that respects: Enq (c) Deq(a|b|c) ? p2 • The seq order in each process • The seq specification of the object The real-time order of the non-overlapping operations • Enq (a) Enq (c) Deq (b) Enq (b) Deq (a) c Michel Raynal Synchronization is coming back! 25 c Michel Raynal Synchronization is coming back! 26 Sequential vs Concurrent (3) Locality of the Linearizability property (1) Enq (a) Enq (b) Deq (a|b|c) ? p1 • A property P of a concurrent system is Local if the system as a whole satisfies P whenever each individual Enq (c) Deq (a|b|c) ? object satisfies P p2 Locality means that, given two objects X and Y , each satisfying the property P , the composite object [X,Y ] satisfies the property P • Linearizability is a local property (consistency criterion) Enq (a) Deq (a) Enq (c) Enq (b) Deq(c) c Michel Raynal Synchronization is coming back! 27 c Michel Raynal Synchronization is coming back! 28 Locality of the Linearizability property (2) Sequential Consistency • An execution (or “history”) H is sequentially consistent if the operations issued by the processes appear as if they have been executed in some sequential order that • Theorem: A history H is linearizable iff, for each object respects each process order and the seq specification X, H restricted to the operations on X is linearizable of every object Locality means that, given two linearizable objects X .Enq( ) and Y , the composite object [X,Y ] is linearizable Q a • It follows that each object can be implemented indepen- dently from the others (this is a fundamental property from both theoretical and practical point of views) Q.Enq(b) Q.Deq(b) • Sequential consistency, some forms of serializability are not local properties A ”witness” seq history: Q.Enq(b) Q.Enq(a) Q.Deq(b) c Michel Raynal Synchronization is coming back! 29 c Michel Raynal Synchronization is coming back! 30 Sequential Consistency is not Local Part III Q.Enq(a) Q′.Enq(b′) Q′.Deq(b′) Q′.Enq(a′) Q.Enq(b) Q.Deq(b) On the LIVENESS side • Q and Q′ are sequentially consistent PROGRESS CONDITIONS • the whole history H is not sequentially consistent Impossibility to produce a “witness” sequential history • See distributed caches c Michel Raynal Synchronization is coming back! 31 c Michel Raynal Synchronization is coming back! 32 Two cases MUTEX-FREEDOM • Reliable systems: • No code is protected by a critical section ⋆ Lock-based implementations ⋆ Progress conditions O.op1() by p1 O.op2(b) by p2 O.op1() by p3 ∗ Deadlock-freedom ∗ Starvation-freedom • Crash-prone systems: ⋆ Mutex-free implmentations R1 R3 R2R3R3 R2R3 R1 R2 R1 ⋆ Associated progress conditions c Michel Raynal Synchronization is coming back! 33 c Michel Raynal Synchronization is coming back! 34 Abortable object Obstruction-freedom • If an operation executes alone (concurrency-free con- • If an operation executes alone (concurrency-free con- text), it terminates and returns a correct value text), it terminates and returns a correct value • If an operation executes in a concurrency context, • If an operation executes in a concurrency context, it terminates and returns a correct value or it returns ⊥ and has no effect on the object ⋆ it can never termination ⋆ if it terminates, its result is correct This definition is different from the one used by Aguilera M.K., Frolund S., Hadzila- cos V., Horn S.L.
Recommended publications
  • ACM SIGACT News Distributed Computing Column 28

    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.
  • Fast and Correct Load-Link/Store-Conditional Instruction Handling in DBT Systems

    Fast and Correct Load-Link/Store-Conditional Instruction Handling in DBT Systems

    Fast and Correct Load-Link/Store-Conditional Instruction Handling in DBT Systems Abstract Atomic Read Memory Dynamic Binary Translation (DBT) requires the implemen- Operation tation of load-link/store-conditional (LL/SC) primitives for guest systems that rely on this form of synchronization. When Equals targeting e.g. x86 host systems, LL/SC guest instructions are YES NO typically emulated using atomic Compare-and-Swap (CAS) expected value? instructions on the host. Whilst this direct mapping is efficient, this approach is problematic due to subtle differences between Write new value LL/SC and CAS semantics. In this paper, we demonstrate that to memory this is a real problem, and we provide code examples that fail to execute correctly on QEMU and a commercial DBT system, Exchanged = true Exchanged = false which both use the CAS approach to LL/SC emulation. We then develop two novel and provably correct LL/SC emula- tion schemes: (1) A purely software based scheme, which uses the DBT system’s page translation cache for correctly se- Figure 1: The compare-and-swap instruction atomically reads lecting between fast, but unsynchronized, and slow, but fully from a memory address, and compares the current value synchronized memory accesses, and (2) a hardware acceler- with an expected value. If these values are equal, then a new ated scheme that leverages hardware transactional memory value is written to memory. The instruction indicates (usually (HTM) provided by the host. We have implemented these two through a return register or flag) whether or not the value was schemes in the Synopsys DesignWare® ARC® nSIM DBT successfully written.
  • Edsger Dijkstra: the Man Who Carried Computer Science on His Shoulders

    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.
  • Mastering Concurrent Computing Through Sequential Thinking

    Mastering Concurrent Computing Through Sequential Thinking

    review articles DOI:10.1145/3363823 we do not have good tools to build ef- A 50-year history of concurrency. ficient, scalable, and reliable concur- rent systems. BY SERGIO RAJSBAUM AND MICHEL RAYNAL Concurrency was once a specialized discipline for experts, but today the chal- lenge is for the entire information tech- nology community because of two dis- ruptive phenomena: the development of Mastering networking communications, and the end of the ability to increase processors speed at an exponential rate. Increases in performance come through concur- Concurrent rency, as in multicore architectures. Concurrency is also critical to achieve fault-tolerant, distributed services, as in global databases, cloud computing, and Computing blockchain applications. Concurrent computing through sequen- tial thinking. Right from the start in the 1960s, the main way of dealing with con- through currency has been by reduction to se- quential reasoning. Transforming problems in the concurrent domain into simpler problems in the sequential Sequential domain, yields benefits for specifying, implementing, and verifying concur- rent programs. It is a two-sided strategy, together with a bridge connecting the Thinking two sides. First, a sequential specificationof an object (or service) that can be ac- key insights ˽ A main way of dealing with the enormous challenges of building concurrent systems is by reduction to sequential I must appeal to the patience of the wondering readers, thinking. Over more than 50 years, more sophisticated techniques have been suffering as I am from the sequential nature of human developed to build complex systems in communication. this way. 12 ˽ The strategy starts by designing —E.W.
  • A Separation Logic for Refining Concurrent Objects

    A Separation Logic for Refining Concurrent Objects

    A Separation Logic for Refining Concurrent Objects Aaron Turon ∗ Mitchell Wand Northeastern University {turon, wand}@ccs.neu.edu Abstract do { tmp = *C; } until CAS(C, tmp, tmp+1); Fine-grained concurrent data structures are crucial for gaining per- implements inc using an optimistic approach: it takes a snapshot formance from multiprocessing, but their design is a subtle art. Re- of the counter without acquiring a lock, computes the new value cent literature has made large strides in verifying these data struc- of the counter, and uses compare-and-set (CAS) to safely install the tures, using either atomicity refinement or separation logic with new value. The key is that CAS compares *C with the value of tmp, rely-guarantee reasoning. In this paper we show how the owner- atomically updating *C with tmp + 1 and returning true if they ship discipline of separation logic can be used to enable atomicity are the same, and just returning false otherwise. refinement, and we develop a new rely-guarantee method that is lo- Even for this simple data structure, the fine-grained imple- calized to the definition of a data structure. We present the first se- mentation significantly outperforms the lock-based implementa- mantics of separation logic that is sensitive to atomicity, and show tion [17]. Likewise, even for this simple example, we would prefer how to control this sensitivity through ownership. The result is a to think of the counter in a more abstract way when reasoning about logic that enables compositional reasoning about atomicity and in- its clients, giving it the following specification: terference, even for programs that use fine-grained synchronization and dynamic memory allocation.
  • Lecture Notes in Computer Science 2584 Edited by G

    Lecture Notes in Computer Science 2584 Edited by G

    Lecture Notes in Computer Science 2584 Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 3 Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo André Schiper Alex A. Shvartsman Hakim Weatherspoon Ben Y. Zhao (Eds.) Future Directions in Distributed Computing Research and Position Papers 13 Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors André Schiper École Polytechnique Fédérale de Lausanne, Faculté Informatique et Communication IN-Ecublens, 1015 Lausanne, Switzerland E-mail: andre.schiper@epfl.ch Alex A. Shvartsman University of Connecticut, Computer Science and Engineering Unit 3155, Storrs, CT 06269, USA E-mail: [email protected] and [email protected] Hakim Weatherspoon Ben Y. Zhao University of California at Berkeley, Computer Science Division 447/443 Soda Hall, Berkeley, CA 94704-1776, USA E-mail: {hweather, ravenben}@cs.berkeley.edu Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliographie; detailed bibliographic data is available in the Internet at <http://dnb.ddb.de>. CR Subject Classification (1998): C.2.4, D.1.3, D.2.12, D.4.3-4, F.1.2 ISSN 0302-9743 ISBN 3-540-00912-4 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks.
  • Lock-Free Programming

    Lock-Free Programming

    Lock-Free Programming Geoff Langdale L31_Lockfree 1 Desynchronization ● This is an interesting topic ● This will (may?) become even more relevant with near ubiquitous multi-processing ● Still: please don’t rewrite any Project 3s! L31_Lockfree 2 Synchronization ● We received notification via the web form that one group has passed the P3/P4 test suite. Congratulations! ● We will be releasing a version of the fork-wait bomb which doesn't make as many assumptions about task id's. – Please look for it today and let us know right away if it causes any trouble for you. ● Personal and group disk quotas have been grown in order to reduce the number of people running out over the weekend – if you try hard enough you'll still be able to do it. L31_Lockfree 3 Outline ● Problems with locking ● Definition of Lock-free programming ● Examples of Lock-free programming ● Linux OS uses of Lock-free data structures ● Miscellanea (higher-level constructs, ‘wait-freedom’) ● Conclusion L31_Lockfree 4 Problems with Locking ● This list is more or less contentious, not equally relevant to all locking situations: – Deadlock – Priority Inversion – Convoying – “Async-signal-safety” – Kill-tolerant availability – Pre-emption tolerance – Overall performance L31_Lockfree 5 Problems with Locking 2 ● Deadlock – Processes that cannot proceed because they are waiting for resources that are held by processes that are waiting for… ● Priority inversion – Low-priority processes hold a lock required by a higher- priority process – Priority inheritance a possible solution L31_Lockfree
  • 31 International Symposium on Distributed Computing Andréa W

    31 International Symposium on Distributed Computing Andréa W

    31 International Symposium on Distributed Computing DISC 2017, October 16–20, Vienna, Austria Edited by Andréa W. Richa LIPIcs – Vol. 91 – DISC2017 www.dagstuhl.de/lipics Editor Andréa W. Richa Computer Science and Engineering School of Computing, Informatics and Decision Systems Engineering (CIDSE) Arizona State University Tempe, AZ, USA [email protected] ACM Classification 1998 C.2 Computer-Communication Networks, C.2.4 Distributed Systems, D.1.3 Concurrent Programming, E.1 Data Structures, F Theory of Computation, F.1.1 Models of Computation, F.1.2 Modes of Computation ISBN 978-3-95977-053-8 Published online and open access by Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH, Dagstuhl Publishing, Saarbrücken/Wadern, Germany. Online available at http://www.dagstuhl.de/dagpub/978-3-95977-053-8. Publication date October, 2017 Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available in the Internet at http://dnb.d-nb.de. License This work is licensed under a Creative Commons Attribution 3.0 Unported license (CC-BY 3.0): http://creativecommons.org/licenses/by/3.0/legalcode. In brief, this license authorizes each and everybody to share (to copy, distribute and transmit) the work under the following conditions, without impairing or restricting the authors’ moral rights: Attribution: The work must be attributed to its authors. The copyright is retained by the corresponding authors. Digital Object Identifier: 10.4230/LIPIcs.DISC.2017.0 ISBN 978-3-95977-053-8 ISSN 1868-8969 http://www.dagstuhl.de/lipics 0:iii LIPIcs – Leibniz International Proceedings in Informatics LIPIcs is a series of high-quality conference proceedings across all fields in informatics.
  • Byzantine Consensus in Asynchronous Message-Passing Systems: a Survey

    Byzantine Consensus in Asynchronous Message-Passing Systems: a Survey

    Int. J. Critical Computer-Based Systems, Vol. x, No. x, xxxx 1 Byzantine Consensus in Asynchronous Message-Passing Systems: a Survey Miguel Correia*, Giuliana Santos Veronese, Nuno Ferreira Neves and Paulo Verissimo Faculdade de Ciˆenciasda Universidade de Lisboa Campo Grande, 1749-016 Lisboa, Portugal E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] E-mail: [email protected] *Corresponding author Abstract Consensus is a classical distributed systems problem with both theo- retical and practical interest. Asynchronous Byzantine consensus is cur- rently at the core of some solutions for the implementation of highly- resilient computing services. This paper surveys Byzantine consensus in message-passing distributed systems, by presenting the main theo- retical results in the area, the main classes of algorithms and by dis- cussing important issues like the performance and resilience of these algorithms. Keywords: distributed algorithms; distributed systems; consensus; Byzantine faults; arbitrary faults; asynchronous model; message pass- ing; Byzantine consensus Reference to this paper should be made as follows: Correia, M., Veronese, G. S., Neves, N. F. and Verissimo, P. (xxxx) ‘Byzantine Con- sensus in Asynchronous Message-Passing Systems: a Survey’, Int. J. Critical Computer-Based Systems, Vol. x, No. x, pp.xxx–xxx. Biographical notes: Miguel Correia is an assistant professor in the Department of Informatics at the Faculty of Sciences at the University of Lisboa, and an adjunct faculty member of the Carnegie Mellon In- formation Networking Institute. More information about his research can be found at http://www.di.fc.ul.pt/∼mpc.
  • Multithreading for Gamedev Students

    Multithreading for Gamedev Students

    Multithreading for Gamedev Students Keith O’Conor 3D Technical Lead Ubisoft Montreal @keithoconor - Who I am - PhD (Trinity College Dublin), Radical Entertainment (shipped Prototype 1 & 2), Ubisoft Montreal (shipped Watch_Dogs & Far Cry 4) - Who this is aimed at - Game programming students who don’t necessarily come from a strict computer science background - Some points might be basic for CS students, but all are relevant to gamedev - Slides available online at fragmentbuffer.com Overview • Hardware support • Common game engine threading models • Race conditions • Synchronization primitives • Atomics & lock-free • Hazards - Start at high level, finish in the basement - Will also talk about potential hazards and give an idea of why multithreading is hard Overview • Only an introduction ◦ Giving a vocabulary ◦ See references for further reading ◦ Learn by doing, hair-pulling - Way too big a topic for a single talk, each section could be its own series of talks Why multithreading? - Hitting power & heat walls when going for increased frequency alone - Go wide instead of fast - Use available resources more efficiently - Taken from http://www.karlrupp.net/2015/06/40-years-of-microprocessor- trend-data/ Hardware multithreading Hardware support - Before we use multithreading in games, we need to understand the various levels of hardware support that allow multiple instructions to be executed in parallel - There are many more aspects to hardware multithreading than we’ll look at here (processor pipelining, cache coherency protocols etc.) - Again,
  • Money Transfer Made Simple Alex Auvolat, Davide Frey, Michel Raynal, François Taïani

    Money Transfer Made Simple Alex Auvolat, Davide Frey, Michel Raynal, François Taïani

    Money Transfer Made Simple Alex Auvolat, Davide Frey, Michel Raynal, François Taïani To cite this version: Alex Auvolat, Davide Frey, Michel Raynal, François Taïani. Money Transfer Made Simple. 2020. hal-02861511v2 HAL Id: hal-02861511 https://hal.archives-ouvertes.fr/hal-02861511v2 Preprint submitted on 17 Jun 2020 (v2), last revised 16 Feb 2021 (v3) HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Money Transfer Made Simple Alex Auvolat École Normale Supérieure, Paris, France Univ Rennes, Inria, CNRS, IRISA, Rennes, France [email protected] Davide Frey Univ Rennes, Inria, CNRS, IRISA, Rennes, France [email protected] Michel Raynal Univ Rennes, Inria, CNRS, IRISA, Rennes, France Department of Computing, Polytechnic University, Hong Kong [email protected] François Taïani Univ Rennes, Inria, CNRS, IRISA, Rennes, France [email protected] Abstract It has recently been shown (PODC 2019) that, contrarily to a common belief, money transfer in the presence of faulty (Byzantine) processes does not require strong agreement such as consensus. This article goes one step further: namely, it shows that money transfers do not need to explicitly capture the causality relation that links individual transfers.
  • CS 241 Honors Concurrent Data Structures

    CS 241 Honors Concurrent Data Structures

    CS 241 Honors Concurrent Data Structures Bhuvan Venkatesh University of Illinois Urbana{Champaign March 7, 2017 CS 241 Course Staff (UIUC) Lock Free Data Structures March 7, 2017 1 / 37 What to go over Terminology What is lock free Example of Lock Free Transactions and Linerazability The ABA problem Drawbacks Use Cases CS 241 Course Staff (UIUC) Lock Free Data Structures March 7, 2017 2 / 37 Atomic instructions - Instructions that happen in one step to the CPU or not at all. Some examples are atomic add, atomic compare and swap. Terminology Transaction - Like atomic operations, either the entire transaction goes through or doesn't. This could be a series of operations (like push or pop for a stack) CS 241 Course Staff (UIUC) Lock Free Data Structures March 7, 2017 3 / 37 Terminology Transaction - Like atomic operations, either the entire transaction goes through or doesn't. This could be a series of operations (like push or pop for a stack) Atomic instructions - Instructions that happen in one step to the CPU or not at all. Some examples are atomic add, atomic compare and swap. CS 241 Course Staff (UIUC) Lock Free Data Structures March 7, 2017 3 / 37 int atomic_cas(int *addr, int *expected, int value){ if(*addr == *expected){ *addr = value; return 1;//swap success }else{ *expected = *addr; return 0;//swap failed } } But this all happens atomically! Atomic Compare and Swap? CS 241 Course Staff (UIUC) Lock Free Data Structures March 7, 2017 4 / 37 But this all happens atomically! Atomic Compare and Swap? int atomic_cas(int *addr, int *expected,