DOCSLIB.ORG

Concurrency in the Linux Kernel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Concurrency in the Linux Kernel Frightening small children and disconcerting grown-ups: Concurrency in the Linux kernel Jade Alglave Luc Maranget Paul E. McKenney University College London Inria — Paris IBM Corporation Microsoft Research [email protected] Oregon State University [email protected] [email protected] Andrea Parri Alan Stern Scuola Superiore Sant’Anna Harvard University [email protected] [email protected] Abstract Model URL SPARC [51, 76] Concurrency in the Linux kernel can be a contentious topic. LK [84] The Linux kernel mailing list features numerous discussions LK [56, 4] related to consistency models, including those of the more LK [19] than 30 CPU architectures supported by the kernel and that LK [73] of the kernel itself. How are Linux programs supposed to LK [36] behave? Do they behave correctly on exotic hardware? LK/Itanium [16, 70] A formal model can help address such questions. Better LK [20] yet, an executable model allows programmers to experiment Itanium [57, 48, 49, 88] with the model to develop their intuition. Thus we offer Intel [53, 41] a model written in the cat language, making it not only LK/C11 [22, 23] formal, but also executable by the herd simulator. We tested LK [21] our model against hardware and refined it in consultation Alpha [79] with maintainers. Finally, we formalised the fundamental LK [31] law of the Read-Copy-Update synchronisation mechanism, ARM64 [26] and proved that one of its implementations satisfies this law. LK [27] MIPS [85, 86, 87, 81] Power [32, 33, 30] 1. Introduction ARM64 [28] Concurrency in Linux may frighten small children [35]; it LK/C11 [24] also appears to be disconcerting to grown-ups. LK [72] Table 1: Selection of LKML discussions 1.1 “Still confusion situation all round” [sic] [89] The Linux kernel (LK) targets more than 30 CPU ar- LK developers must understand not only the kernel’s concur- chitectures, amongst which Alpha [18], ARM [14], IBM rency primitives, but also those of the underlying hardware. Power [38], Intel [40], Itanium [40] and MIPS [39] imple- Several documents make laudable efforts in this direction: ment weak consistency models. Consistency models deter- [37] lists what orderings are guaranteed; [69] summarises mine what values a read can take; weak models allow more semantics of read-modify-write operations, and [55] doc- behaviours than Sequential Consistency (SC) [45]. uments ways of avoiding counterproductive optimisations. These architectures implement distinct models and thus Sadly these documents are in prose, subject to ambiguities disagree on the values that a read can return. This leads to and misinterpretations. As a candid disclaimer puts it [37]: a plethora of discussions on the Linux Kernel mailing list This document is not a specification; it is intentionally (for the (LKML), some of which are listed in Table 1; their frequency sake of brevity) and unintentionally (due to being human) incom- has increased as multicore systems have gone mainstream. plete. [. ] in case of any doubt (and there are many) please ask. This quote suggests that a specification might dispel all doubts. However, as Linus Torvalds writes [78]: In short, the LK should have a model of its own. With specs, there really *are* people who spend years discussing 1.3 “[P]ick a sane, maintainable memory model” what the meaning of the word ”access” is or similar [the authors [71] of this paper plead guilty]. Combine that with a big spec that is Our LK model is a first attempt at fulfilling this wish. Of 500+ pages in size and then try to apply that all to a project that is 15 million lines of code and sometimes *knowingly* has to do course, concerns like sanity or maintainability are to an things that it simply knows are outside the spec [...]” extent in the eye of the beholder. But we believe that the LK community will help achieve these goals. Indeed, our This highlights the need for an object beyond a prose work is based on interactions with the community, along specification: unambiguous, concise, amenable to vast code with documentation and posts to mailing lists. This has been projects, and complete. We offer a formal executable model necessary for understanding the semantics of certain pieces for the LK, written in the cat language [12]. of code. Writing a memory consistency model in cat gives it a for- LK issue URL mal meaning, since cat has a formal semantics [3]. More- locking on ARM64 [26] over, a cat model can be executed within the herd tool [5], ambiguities in [37] [59] allowing users to experiment with the model to develop their ambiguities in RCU documentation [58] intuition. CPU hotplug [90] 1.2 “[I]t is your kernel, so what is your preference?” [54] assumption about lock-unlock [64] semantics of spin unlock wait [83] Architects and standard committees are often seen as ulti- Table 2: LK issues that our work helped address mate authorities on consistency matters. In our case, we rely on Linus Torvalds’s and his maintainers’ posts to LKML and Moreover, our model has already resolved ambiguities the gcc mailing list. We cite and discuss these posts below. and helped fix bugs (see Table 2). The RCU documentation A common denominator of hardware models seems to now uses our definitions [58] and memory-barriers.txt [37] align with Torvalds’ view [80]: was updated to distinguish between transitivity and cumu- Weak memory ordering is [. ] hard to think about [. ] So the lativity [59]. Our work informed fixes to code incorrectly memory ordering rules should [. ] absolutely be as tight as at relying on fully ordered lock-unlock pairs [64], code where all humanly possible, given real hardware constraints. ARM64 needed stronger ordering from combinations of To this end, we axiomatised models of IBM Power [75, locking and fences [26], and discussions about the semantics 74] in cat. We modified this formalisation to handle Al- of locking primitives [83]. Finally, our model was directly pha [18] and incorporate ideas from academic ARM mod- used by a maintainer to justify his patch [90]; this highlights els [34]. ARM then released their official memory model [47, the practical applicability of our model. Chap. B2.3] (including a cat file distributed within the Seven maintainers agreed to sponsor our model, which diy+herd toolsuite [5]), making those models obsolete; we has received positive feedback on LKML [60]. thus modified our LK model accordingly. This experience 1.4 Correctness of concurrent code shows that our model will change over time as existing hard- ware evolves, or new hardware arises. Our model is also a stepping stone towards assessing the cor- Yet the LK cannot simply be an envelope for the architec- rectness of LK code. We focus here on Read-Copy-Update tures it supports. As Ingo Molnar writes [71]: (RCU) [52]. CBMC [17] has been used to verify LK Tree RCU over it’s not true that Linux has to offer a barrier and locking model that panders to the weakest (and craziest!) memory ordering SC, TSO, and PSO [46]; others used Nidhugg over SC and model amongst all the possible Linux platforms—theoretical or TSO [42]. Userspace RCU has been examined with respect real metal. Instead what we want to do is to consciously, intelli- to C11 [77, 43]. These works provided valuable insights, but gently pick a sane, maintainable memory model and offer primi- only relative to the models available to them. We examine tives for that—at least as far as generic code is concerned. Each RCU in the light of our LK model, the first to provide a architecture can map those primitives to the best of its abilities. formal semantics for RCU. Moreover, our results provide This seems much like defining a language-level model: it two alternative ways to integrate a semantics of RCU in a might appear that the C11 model could be used as the LK software analysis tool. model. Indeed, converging with C11 is the topic of several 1.5 Overview of the paper and contributions LKML discussions [22, 24]. Unfortunately the C11 model is an imperfect fit [78]: Section 2 introduces LK programs and their executions, and I do not believe for a second that we can actually use the C11 the cat language. Section 3 describes and illustrates our memory model in the kernel [. ] We will continue to have to do model. Section 4 formalises RCU. Section 5 gives our ex- things that are “outside the specs” [. ] with models that C11 perimental results. Section 6 examines the correctness of an simply doesn’t cover. RCU implementation. In summary, this paper presents: 1. a formal core LK memory model, in the form of a spec- LK/C primitive Event ification of the model in cat (Figure 8) and precise con- READ ONCE() R[once] straints under which executions are allowed or forbidden WRITE ONCE() W[once] by the LK model (Figure 3); smp load acquire() R[acquire] 2. examples illustrating how forbidden executions violate smp store release() W[release] the constraints (Figures 2, 4, 5, 6, and 7); smp rmb() F[rmb] smp wmb() F[wmb] 3. a formalisation of RCU as an axiom (Figure 12); smp mb() F[mb] 4. a formalisation of the fundamental law of RCU [62], smp read barrier depends() F[rb-dep] equivalent to the axiom (Theorem 1); xchg relaxed() R[once]; W[once] 5. experiments showing that our model is sound with re- xchg acquire() R[acquire]; W[once] spect to hardware, and a comparison with C11 (Table 5); xchg release() R[once]; W[release] xchg() F[mb]; R[once]; W[once]; F[mb] 6.
Load more

Recommended publications
  • Memory Consistency
    Lecture 9: Memory Consistency Parallel Computing Stanford CS149, Winter 2019 Midterm ▪ Feb 12 ▪ Open notes ▪ Practice midterm Stanford CS149, Winter 2019 Shared Memory Behavior ▪ Intuition says loads should return latest value written - What is latest? - Coherence: only one memory location - Consistency: apparent ordering for all locations - Order in which memory operations performed by one thread become visible to other threads ▪ Affects - Programmability: how programmers reason about program behavior - Allowed behavior of multithreaded programs executing with shared memory - Performance: limits HW/SW optimizations that can be used - Reordering memory operations to hide latency Stanford CS149, Winter 2019 Today: what you should know ▪ Understand the motivation for relaxed consistency models ▪ Understand the implications of relaxing W→R ordering Stanford CS149, Winter 2019 Today: who should care ▪ Anyone who: - Wants to implement a synchronization library - Will ever work a job in kernel (or driver) development - Seeks to implement lock-free data structures * - Does any of the above on ARM processors ** * Topic of a later lecture ** For reasons to be described later Stanford CS149, Winter 2019 Memory coherence vs. memory consistency ▪ Memory coherence defines requirements for the observed Observed chronology of operations on address X behavior of reads and writes to the same memory location - All processors must agree on the order of reads/writes to X P0 write: 5 - In other words: it is possible to put all operations involving X on a timeline such P1 read (5) that the observations of all processors are consistent with that timeline P2 write: 10 ▪ Memory consistency defines the behavior of reads and writes to different locations (as observed by other processors) P2 write: 11 - Coherence only guarantees that writes to address X will eventually propagate to other processors P1 read (11) - Consistency deals with when writes to X propagate to other processors, relative to reads and writes to other addresses Stanford CS149, Winter 2019 Coherence vs.
    [Show full text]
  • RCU Usage in the Linux Kernel: One Decade Later
    RCU Usage In the Linux Kernel: One Decade Later Paul E. McKenney Silas Boyd-Wickizer Jonathan Walpole Linux Technology Center MIT CSAIL Computer Science Department IBM Beaverton Portland State University Abstract unique among the commonly used kernels. Understand- ing RCU is now a prerequisite for understanding the Linux Read-copy update (RCU) is a scalable high-performance implementation and its performance. synchronization mechanism implemented in the Linux The success of RCU is, in part, due to its high perfor- kernel. RCU’s novel properties include support for con- mance in the presence of concurrent readers and updaters. current reading and writing, and highly optimized inter- The RCU API facilitates this with two relatively simple CPU synchronization. Since RCU’s introduction into the primitives: readers access data structures within RCU Linux kernel over a decade ago its usage has continued to read-side critical sections, while updaters use RCU syn- expand. Today, most kernel subsystems use RCU. This chronization to wait for all pre-existing RCU read-side paper discusses the requirements that drove the devel- critical sections to complete. When combined, these prim- opment of RCU, the design and API of the Linux RCU itives allow threads to concurrently read data structures, implementation, and how kernel developers apply RCU. even while other threads are updating them. This paper describes the performance requirements that 1 Introduction led to the development of RCU, gives an overview of the RCU API and implementation, and examines how ker- The first Linux kernel to include multiprocessor support nel developers have used RCU to optimize kernel perfor- is not quite 20 years old.
    [Show full text]
  • Memory Ordering: a Value-Based Approach
    Memory Ordering: A Value-Based Approach Harold W. Cain Mikko H. Lipasti Computer Sciences Dept. Dept. of Elec. and Comp. Engr. Univ. of Wisconsin-Madison Univ. of Wisconsin-Madison [email protected] [email protected] Abstract queues, etc.) used to find independent operations and cor- rectly execute them out of program order are often con- Conventional out-of-order processors employ a multi- strained by clock cycle time. In order to decrease clock ported, fully-associative load queue to guarantee correct cycle time, the size of these conventional structures must memory reference order both within a single thread of exe- usually decrease, also decreasing IPC. Conversely, IPC cution and across threads in a multiprocessor system. As may be increased by increasing their size, but this also improvements in process technology and pipelining lead to increases their access time and may degrade clock fre- higher clock frequencies, scaling this complex structure to quency. accommodate a larger number of in-flight loads becomes There has been much recent research on mitigating this difficult if not impossible. Furthermore, each access to this negative feedback loop by scaling structures in ways that complex structure consumes excessive amounts of energy. are amenable to high clock frequencies without negatively In this paper, we solve the associative load queue scalabil- affecting IPC. Much of this work has focused on the ity problem by completely eliminating the associative load instruction issue queue, physical register file, and bypass queue. Instead, data dependences and memory consistency paths, but very little has focused on the load queue or store constraints are enforced by simply re-executing load queue [1][18][21].
    [Show full text]
  • LMAX Disruptor
    Disruptor: High performance alternative to bounded queues for exchanging data between concurrent threads Martin Thompson Dave Farley Michael Barker Patricia Gee Andrew Stewart May-2011 http://code.google.com/p/disruptor/ 1 Abstract LMAX was established to create a very high performance financial exchange. As part of our work to accomplish this goal we have evaluated several approaches to the design of such a system, but as we began to measure these we ran into some fundamental limits with conventional approaches. Many applications depend on queues to exchange data between processing stages. Our performance testing showed that the latency costs, when using queues in this way, were in the same order of magnitude as the cost of IO operations to disk (RAID or SSD based disk system) – dramatically slow. If there are multiple queues in an end-to-end operation, this will add hundreds of microseconds to the overall latency. There is clearly room for optimisation. Further investigation and a focus on the computer science made us realise that the conflation of concerns inherent in conventional approaches, (e.g. queues and processing nodes) leads to contention in multi-threaded implementations, suggesting that there may be a better approach. Thinking about how modern CPUs work, something we like to call “mechanical sympathy”, using good design practices with a strong focus on teasing apart the concerns, we came up with a data structure and a pattern of use that we have called the Disruptor. Testing has shown that the mean latency using the Disruptor for a three-stage pipeline is 3 orders of magnitude lower than an equivalent queue-based approach.
    [Show full text]
  • A Thread Synchronization Model for the PREEMPT RT Linux Kernel
    A Thread Synchronization Model for the PREEMPT RT Linux Kernel Daniel B. de Oliveiraa,b,c, R^omulo S. de Oliveirab, Tommaso Cucinottac aRHEL Platform/Real-time Team, Red Hat, Inc., Pisa, Italy. bDepartment of Systems Automation, UFSC, Florian´opolis, Brazil. cRETIS Lab, Scuola Superiore Sant'Anna, Pisa, Italy. Abstract This article proposes an automata-based model for describing and validating sequences of kernel events in Linux PREEMPT RT and how they influence the timeline of threads' execu- tion, comprising preemption control, interrupt handling and control, scheduling and locking. This article also presents an extension of the Linux tracing framework that enables the trac- ing of kernel events to verify the consistency of the kernel execution compared to the event sequences that are legal according to the formal model. This enables cross-checking of a kernel behavior against the formalized one, and in case of inconsistency, it pinpoints possible areas of improvement of the kernel, useful for regression testing. Indeed, we describe in details three problems in the kernel revealed by using the proposed technique, along with a short summary on how we reported and proposed fixes to the Linux kernel community. As an example of the usage of the model, the analysis of the events involved in the activation of the highest priority thread is presented, describing the delays occurred in this operation in the same granularity used by kernel developers. This illustrates how it is possible to take advantage of the model for analyzing the preemption model of Linux. Keywords: Real-time computing, Operating systems, Linux kernel, Automata, Software verification, Synchronization.
    [Show full text]
  • Review Der Linux Kernel Sourcen Von 4.9 Auf 4.10
    Review der Linux Kernel Sourcen von 4.9 auf 4.10 Reviewed by: Tested by: stecan stecan Period of Review: Period of Test: From: Thursday, 11 January 2018 07:26:18 o'clock +01: From: Thursday, 11 January 2018 07:26:18 o'clock +01: To: Thursday, 11 January 2018 07:44:27 o'clock +01: To: Thursday, 11 January 2018 07:44:27 o'clock +01: Report automatically generated with: LxrDifferenceTable, V0.9.2.548 Provided by: Certified by: Approved by: Account: stecan Name / Department: Date: Friday, 4 May 2018 13:43:07 o'clock CEST Signature: Review_4.10_0_to_1000.pdf Page 1 of 793 May 04, 2018 Review der Linux Kernel Sourcen von 4.9 auf 4.10 Line Link NR. Descriptions 1 .mailmap#0140 Repo: 9ebf73b275f0 Stephen Tue Jan 10 16:57:57 2017 -0800 Description: mailmap: add codeaurora.org names for nameless email commits ----------- Some codeaurora.org emails have crept in but the names don't exist for them. Add the names for the emails so git can match everyone up. Link: http://lkml.kernel.org/r/[email protected] 2 .mailmap#0154 3 .mailmap#0160 4 CREDITS#2481 Repo: 0c59d28121b9 Arnaldo Mon Feb 13 14:15:44 2017 -0300 Description: MAINTAINERS: Remove old e-mail address ----------- The ghostprotocols.net domain is not working, remove it from CREDITS and MAINTAINERS, and change the status to "Odd fixes", and since I haven't been maintaining those, remove my address from there. CREDITS: Remove outdated address information ----------- This address hasn't been accurate for several years now.
    [Show full text]
  • Linux Foundation Collaboration Summit 2010
    Linux Foundation Collaboration Summit 2010 LTTng, State of the Union Presentation at: http://www.efficios.com/lfcs2010 E-mail: [email protected] Mathieu Desnoyers April 15th, 2010 1 > Presenter ● Mathieu Desnoyers ● EfficiOS Inc. ● http://www.efficios.com ● Author/Maintainer of ● LTTng, LTTV, Userspace RCU ● Ph.D. in computer engineering ● Low-Impact Operating System Tracing Mathieu Desnoyers April 15th, 2010 2 > Plan ● Current state of LTTng ● State of kernel tracing in Linux ● User requirements ● Vertical vs Horizontal integration ● LTTng roadmap for 2010 ● Conclusion Mathieu Desnoyers April 15th, 2010 3 > Current status of LTTng ● LTTng dual-licensing: GPLv2/LGPLv2.1 ● UST user-space tracer – Userspace RCU (LGPLv2.1) ● Eclipse Linux Tools Project LTTng Integration ● User-space static tracepoint integration with gdb ● LTTng kernel tracer – maintainance-mode in 2009 (finished my Ph.D.) – active development restarting in 2010 Mathieu Desnoyers April 15th, 2010 4 > LTTng dual-licensing GPLv2/LGPLv2.1 ● LGPLv2.1 license is required to share code with user-space tracer library. ● License chosen to allow tracing of non-GPL applications. ● Headers are licensed under BSD: – Demonstrates that these headers can be included in non-GPL code. ● Applies to: – LTTng, Tracepoints, Kernel Markers, Immediate Values Mathieu Desnoyers April 15th, 2010 5 > User-space Tracing (UST) (1) ● LTTng port to user-space ● Re-uses Tracepoints and LTTng ring buffer ● Uses Userspace RCU for control synchronization ● Shared memory map with consumer daemon ● Per-process per-cpu ring buffers Mathieu Desnoyers April 15th, 2010 6 > User-space Tracing (UST) (2) ● The road ahead – Userspace trace clock for more architectures ● Some require Linux kernel vDSO support for trace clock – Utrace ● Provide information about thread creation, exec(), etc..
    [Show full text]
  • Read-Copy Update (RCU)
    COMP 790: OS Implementation Read-Copy Update (RCU) Don Porter COMP 790: OS Implementation Logical Diagram Binary Memory Threads Formats Allocators User Today’s Lecture System Calls Kernel RCU File System Networking Sync Memory Device CPU Management Drivers Scheduler Hardware Interrupts Disk Net Consistency COMP 790: OS Implementation RCU in a nutshell • Think about data structures that are mostly read, occasionally written – Like the Linux dcache • RW locks allow concurrent reads – Still require an atomic decrement of a lock counter – Atomic ops are expensive • Idea: Only require locks for writers; carefully update data structure so readers see consistent views of data COMP 790: OS Implementation Motivation (from Paul McKenney’s Thesis) 35 "ideal" "global" 30 "globalrw" 25 20 Performance of RW 15 lock only marginally 10 better than mutex 5 lock Hash Table Searches per Microsecond 0 1 2 3 4 # CPUs COMP 790: OS Implementation Principle (1/2) • Locks have an acquire and release cost – Substantial, since atomic ops are expensive • For short critical regions, this cost dominates performance COMP 790: OS Implementation Principle (2/2) • Reader/writer locks may allow critical regions to execute in parallel • But they still serialize the increment and decrement of the read count with atomic instructions – Atomic instructions performance decreases as more CPUs try to do them at the same time • The read lock itself becomes a scalability bottleneck, even if the data it protects is read 99% of the time COMP 790: OS Implementation Lock-free data structures
    [Show full text]
  • Connect User Guide Armv8-A Memory Systems
    ARMv8-A Memory Systems ConnectARMv8- UserA Memory Guide VersionSystems 0.1 Version 1.0 Copyright © 2016 ARM Limited or its affiliates. All rights reserved. Page 1 of 17 ARM 100941_0100_en ARMv8-A Memory Systems Revision Information The following revisions have been made to this User Guide. Date Issue Confidentiality Change 28 February 2017 0100 Non-Confidential First release Proprietary Notice Words and logos marked with ® or ™ are registered trademarks or trademarks of ARM® in the EU and other countries, except as otherwise stated below in this proprietary notice. Other brands and names mentioned herein may be the trademarks of their respective owners. Neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder. The product described in this document is subject to continuous developments and improvements. All particulars of the product and its use contained in this document are given by ARM in good faith. However, all warranties implied or expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded. This document is intended only to assist the reader in the use of the product. ARM shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product. Where the term ARM is used it means “ARM or any of its subsidiaries as appropriate”. Confidentiality Status This document is Confidential.
    [Show full text]
  • Using Visualization to Understand the Behavior of Computer Systems
    USING VISUALIZATION TO UNDERSTAND THE BEHAVIOR OF COMPUTER SYSTEMS A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY Robert P. Bosch Jr. August 2001 c Copyright by Robert P. Bosch Jr. 2001 All Rights Reserved ii I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Dr. Mendel Rosenblum (Principal Advisor) I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Dr. Pat Hanrahan I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Dr. Mark Horowitz Approved for the University Committee on Graduate Studies: iii Abstract As computer systems continue to grow rapidly in both complexity and scale, developers need tools to help them understand the behavior and performance of these systems. While information visu- alization is a promising technique, most existing computer systems visualizations have focused on very specific problems and data sources, limiting their applicability. This dissertation introduces Rivet, a general-purpose environment for the development of com- puter systems visualizations. Rivet can be used for both real-time and post-mortem analyses of data from a wide variety of sources. The modular architecture of Rivet enables sophisticated visualiza- tions to be assembled using simple building blocks representing the data, the visual representations, and the mappings between them.
    [Show full text]
  • Evolutionary Tree-Structured Storage: Concepts, Interfaces, and Applications
    Evolutionary Tree-Structured Storage: Concepts, Interfaces, and Applications Dissertation submitted for the degree of Doctor of Natural Sciences Presented by Marc Yves Maria Kramis at the Faculty of Sciences Department of Computer and Information Science Date of the oral examination: 22.04.2014 First supervisor: Prof. Dr. Marcel Waldvogel Second supervisor: Prof. Dr. Marc Scholl i Abstract Life is subdued to constant evolution. So is our data, be it in research, business or personal information management. From a natural, evolutionary perspective, our data evolves through a sequence of fine-granular modifications resulting in myriads of states, each describing our data at a given point in time. From a technical, anti- evolutionary perspective, mainly driven by technological and financial limitations, we treat the modifications as transient commands and only store the latest state of our data. It is surprising that the current approach is to ignore the natural evolution and to willfully forget about the sequence of modifications and therefore the past state. Sticking to this approach causes all kinds of confusion, complexity, and performance issues. Confusion, because we still somehow want to retrieve past state but are not sure how. Complexity, because we must repeatedly work around our own obsolete approaches. Performance issues, because confusion times complexity hurts. It is not surprising, however, that intelligence agencies notoriously try to collect, store, and analyze what the broad public willfully forgets. Significantly faster and cheaper random-access storage is the key driver for a paradigm shift towards remembering the sequence of modifications. We claim that (1) faster storage allows to efficiently and cleverly handle finer-granular modifi- cations and (2) that mandatory versioning elegantly exposes past state, radically simplifies the applications, and effectively lays a solid foundation for backing up, distributing and scaling of our data.
    [Show full text]
  • Interrupt Handling
    CCChahahaptptpteeerrr 555 KKKeeerrrnnneeelll SSSyyynnnccchhhrrrooonnniiizzzaaatttionionion Hsung-Pin Chang Department of Computer Science National Chung Hsing University Outline • Kernel Control Paths • When Synchronization Is Not Necessary • Synchronization Primitives • Synchronizing Accesses to Kernel Data Structure • Examples of Race Condition Prevention Kernel Control Paths • Kernel control path – A sequence of instructions executed by the kernel to handle interrupts of different kinds – Each kernel request is handled by a different kernel control path Kernel Control Paths (Cont.) • Kernel requests may be issued in several possible ways – A process executing in User Mode causes an exception-for instance, by executing at int0x80 instruction – An external devices sends a signal to a Programmable Interrupt Controller Kernel Control Paths (Cont.) – A process executing in Kernel Mode causes a Page Fault exception – A process running in a MP system and executing in Kernel Mode raises an interprocessorinterrupt Kernel Control Paths (Cont.) • Kernel control path is quite similar to the process, except – Does not have a descriptor – Not scheduled through scheduler, but rather by inserting sequence of instructions into the kernel code Kernel Control Paths (Cont.) • In some cases, the CPU interleaves kernel control paths when one of the following event occurs – A process switch occurs, i.e., when the schedule() function is invoked – An interrupt occurs while the CPU is running a kernel control path with interrupt enabled – A deferrable function
    [Show full text]