1 / 27

Atomic transactions

Atomic transactions. Mutual exclusion is a low-level concept, like message-passing, and semaphores We want a higher-level abstraction that makes it easier to write and reason about programs Atomic transactions (from the business world)

romney
Download Presentation

Atomic transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Atomic transactions • Mutual exclusion is a low-level concept, like message-passing, and semaphores • We want a higher-level abstraction that makes it easier to write and reason about programs • Atomic transactions (from the business world) • Dingbat corporation needs widgets, they approach US Widget for a quote on 100,000 10cm purple widgets for June • US Widget offers 100,000 4in fuschia widgets for delivery in December • After negotiation, they agree on 3 959/1024 inch violet widgets for delivery in August Computing Systems

  2. Atomic transactions • Jason wants to transfer money from BofA to Wells Fargo • Withdraw ($10000, BofA.jyh) • Charter cuts the cable connection • Deposit ($10000, WF.jyh) • An atomic transaction would solve the problem • Either: both operations complete, or neither completes Computing Systems

  3. Transaction primitives • e ::= atomic { e} | abort | read | write | e1; e2 | ... • Example, reserve flight from LAX to Malindi Computing Systems

  4. Properties of transactions • Atomic: to the outside world, the transaction is indivisible • Consistent: the transaction preserves system invariants • Isolated: two transactions do not interfere • Durable: once a transaction commits, the changes are permanent • (ACID) Computing Systems

  5. Properties • Atomic • Suppose a transaction starts writing to a file that had 10 bytes in it • Other processes will not see the additional data until the transaction commits • Consistent • The transaction should preserve properties • Conservation of money: the invariant may be violated during the transaction, but the violation is not visible outside the transaction Computing Systems

  6. Properties • Isolated (serializable) • If two transactions are running concurrently, the final result looks as if the two operations happened in some order Computing Systems

  7. Implementing transactions • Assume all state operations are on files • Easiest solution: copy-on-write • BEGIN_ATOMIC(fd): fork the file descriptor/inode • READ(fd, block): read the data • WRITE(fd, block): insert the new block • END_ATOMIC(fd): commit the changes Computing Systems

  8. INODE+FILE Computing Systems

  9. BEGIN_ATOMIC Computing Systems

  10. WRITE Computing Systems

  11. END_ATOMIC Computing Systems

  12. END_ATOMIC Computing Systems

  13. Atomic transactions • In general, multiple files will be modified by a transaction • Commit must be simultaneous • OS supports atomic, simultaneous, inode update • Distributed FS, broadcast commit • Nested transactions • inode copies form a tree Computing Systems

  14. Theoretical programming models • The search for a foundation of distributed programming • Features • Nondeterminism • Nondeterminism is a necessary feature of parallel programming • Nondeterministic programs are more abstract • Absence of control flow • Why is it necessary to order program statements? • Module: interface and implementation, the control flow is a separate issue Computing Systems

  15. Programming models • Synchrony and asynchrony should be considered as fundamental concepts • State-transition systems • Computer scientists: models of formal programming languages • Control theorists: continuous and discrete transition systems • Communication engineers: channel is a state-transition system Computing Systems

  16. UNITY (Chandy & Misra) • Emplpy the theory of state-transition systems, with representational advantages of programming languages • A program is a set of guarded assignment statements • Assignments are executed atomically in arbitrary (but fair) order • Plus initialization Computing Systems

  17. A note from Backus • “The assignment statement splits programming into two worlds. The first world is the world of the right-hand sides. This is an orderly world of expressions with useful algebraic properties. It is the world in which most useful computation takes place. • The second world is the world of statements. The primary statement is the assignment statement itself. All the other statements exists in order to make it possible to perform a computation that is based on this primitive construct: the assignment statement itself. • The world of statements is a disorderly one, with few useful mathematical properties. Structured programming can be seen as a modest effort to introduce some order to this chaotic world, but it accomplishes little in attacking the fundamental problems created by word-at-a-time von Neumann style of programming. Computing Systems

  18. UNITY programs • A program consists of: • declarations of variables • specification of their initial values • a set of multiple-assignment statements Computing Systems

  19. Example: scheduling a meeting • Specification: “find the earliest time acceptable to each person in a group” • Call them F, G, H, with functions f, g, h • f(t) is the earliest time at or after t when person F can meet • f is monotone (f(t) >= t), and idempotent (f(f(t)) = f(t)) • Define • com(t) = (t = f(t) = g(t) = h(t)) • Find, within finite time • r = min { t | com(t) } Computing Systems

  20. Possible implementation • Pass a token around the table • Use a coordinator, who broadcasts next round of times • Divide and conquer • Use an auctioneer Computing Systems

  21. Program design process • Take the specification as a starting point for design • Propose programs, until one of them meets the spec • Refine the specification to a “correct” program Computing Systems

  22. First program Computing Systems

  23. von Neumann machine: iterate until the first value is found, O(z) parallel synchronous machine: O(log z) steps for O(z) processors Refinement: it is not necessary to consider values between t and f(t) Implementing P1 Computing Systems

  24. Second program Computing Systems

  25. Choose any assignment statement and evaluate it Compute until a fixpoint is reached Correctness Invariant: for all times t < r, t is not a suitable meeting time Prove this by induction Show it is true when the program starts Show that it is true after executing any of the assignment statements Abstract evaluation Computing Systems

  26. von Neumann: execute statements in some order until a fixpoint is reached Different schedules may have better performance Compiling to various architectures Computing Systems

  27. Partition statements over several processors (that share memory) For example, one processor for each assignment Another program: central coordinator Parallel machine Computing Systems

More Related