COMP3151/9151 Foundations of Concurrency Lecture 8

Transcription

1 1 COMP3151/9151 Foundations of Concurrency Lecture 8 Liam O Connor CSE, UNSW (and data61) 8 Sept 2017

2 2 Shared Data Consider the Readers and Writers problem from Lecture 6: Problem We have a large data structure (i.e. a structure that cannot be updated in one atomic step) that is shared between some number of writers who are updating the data structure and some number of readers who are attempting to retrieve a coherent copy of the data structure. Desiderata: We want atomicity, in that each update happens in one go, and updates-in-progress or partial updates are not observable. We want consistency, in that any reader that starts after an update finishes will see that update. We want to minimise waiting.

3 3 A Crappy Solution Treat both reads and updates as critical sections use any old critical section solution (mutexes, semaphores, etc.) to sequentialise all reads and writes to the data structure. Observation Updates are atomic and reads are consistent but reads can t happen concurrently, which leads to unnecessary contention.

4 4 A Better Solution Use a monitor with two condition variables. See Algorithm 6.12 of the slides or Ben-Ari s Algorithm 7.4. Observation We have atomicity and consistency, and now multiple reads can execute concurrently. Still, we don t allow updates to execute concurrently with reads, to prevent partial updates from being observed by a reader.

5 5 Complication Reading and Writing Now suppose we don t want readers to wait (much) while an update is performed. Instead, we d rather they get an older version of the data structure. Trick: Rather than update the data structure in place, a writer creates their own local copy of the data structure, and then merely updates the (shared) pointer to the data structure to point to their copy. Liam: Draw on the board Atomicity The only shared write is now just to one pointer. Consistency Reads that start before the pointer update get the older version, but reads that start after get the latest.

6 6 Persistent Data Structures Copying is O(n) in the worst case, but we can do better for many tree-like types of data structure. Example (Binary Search Tree) Pointer

7 7 Persistent Data Structures Copying is O(n) in the worst case, but we can do better for many tree-like types of data structure. Example (Binary Search Tree) Pointer

8 8 Persistent Data Structures Copying is O(n) in the worst case, but we can do better for many tree-like types of data structure. Example (Binary Search Tree) Pointer

9 9 Persistent Data Structures Copying is O(n) in the worst case, but we can do better for many tree-like types of data structure. Example (Binary Search Tree) Pointer

10 10 Purely Functional Data Structures Persistent data structures that exclusively make use of copying over mutation are called purely functional data structures. They are so called because operations on them are best expressed in the form of mathematical functions that, given an input structure, return a new output structure: insert v Leaf = Branch v Leaf Leaf insert v (Branch x l r) = if v x then Branch x (insert v l) r else Branch x l (insert v r) Purely functional programming languages like Haskell are designed to facilitate programming in this way.

11 11 Haskell Haskell is a programming language where all programs are written in the form of immutable definitions. There is no intrinsic notion of time or mutable state. Syntax is mostly derived from simple mathematical notation. Example (Factorial) Liam: Show more examples, use GHCi a bit factorial :: Int Int factorial 0 = 1 factorial n = n factorial (n 1)

12 12 Computing with Functions Unfortunately, pure functions don t capture everything we want from computations. Processes have to interact with the user, global state, other processes, and the operating system. We model real processes in Haskell using the IO type. IO τ = A (possibly effectful) process that, when executed, produces a result of type τ Note the semantics of evaluation and execution are different things.

13 13 Building up IO pure :: a. a IO a ( =) :: a b. IO a (a IO b) IO b getchar :: IO Char putchar :: Char IO () Example (Echo) echo :: IO () echo = getchar = (λx. putchar x = λy. echo) (here λx. y is notation for an anonymous function that returns y given argument x)

14 Monadic IO Monad Laws Define a sequential composition operator IO as follows: ( IO ) :: a b c. (a IO b) (b IO c) (a IO c) (f IO g) x = f x = g We have the following laws to aid reasoning: Identity f IO pure = f = pure IO f Associativity f IO (g IO h) = (f IO g) IO h 14

15 15 Do Notation Haskell defines some convenience notation to make writing processes easier. do x P; Q = P = λx. do Q do P; Q = P = λ. do Q do P = P Example (Echo, revisited) echo :: IO () echo = do x getchar putchar x echo

16 16 Adding Concurrency We can have multiple threads easily enough: forkio :: IO () IO () Example (Dueling Printers) let loop c = do putchar c; loop c in do forkio (loop a ); loop z But what sort of synchronisation primitives are available?

17 17 MVars The MVar is the simplest synchronisation primitive in Haskell. It can be thought of as a shared box which holds at most one value. Threads must take the value out of a full box to read it, and must put a value into an empty box to update it. MVar Functions newmvar :: a. a IO (MVar a) takemvar :: a. MVar a IO a putmvar :: a. MVar a a IO () Create a new MVar Read/remove the value Update/insert a value Taking from an empty MVar or putting into a full one results in blocking. An MVar can be thought of as channel containing at most one value.

18 18 Readers and Writers We can treat MVars as shared variables with some definitions: writemvar m v = do takemvar m; putmvar m v readmvar m = do v takemvar m; putmvar m v; pure v problem :: DB IO () problem initial = do db newmvar initial wl newmvar () let reader = readmvar db = let writer = do takemvar wl d readmvar db let d = update d evaluate d writemvar db d putmvar wl ()

19 19 Fairness Each MVar has an attached FIFO queue, so GHC Haskell can ensure the following fairness property: No thread can be blocked indefinitely on an MVar unless another thread holds that MVar indefinitely. In LTL, this is something like (where L m is the queue for MVar m): (p L m putmvar(m)) (p / L m ) It seems to me that a stronger guarantee can be made, but this is what is stated in the literature.

20 20 Evaluation Semantics The semantics of Haskell s evaluation are interesting but not particularly relevant for us. We will assume that it happens quietly without a fuss: β-equivalence (λx. M[x]) N β M[N] α-equivalence λx. M[x] α λy. M[y] η-equivalence λx. M x η M Let our ambient congruence relation be αβη enriched with the following extra equations, justified by the monad laws: pure N = M M N (X = Y ) = Z X = (λx. Y x = Z) X X = pure

21 21 Processes This means that a Haskell expression of type IO τ for will boil down to either pure x where x is a value of type τ; or a = M where a is some primitive IO action (forkio p, readmvar v, etc.) and M is some function producing another IO τ. This is the head normal form for IO expressions. Definition Define a language of processes P, which contains all (head-normal) expressions of type IO (). We want to define the semantics of the execution of these processes. Let s use operational semantics: ( ) P P

22 22 Semantics for forkio To model forkio, we need to model the parallel execution of multiple processes in our process language. We shall add a parallel composition operator to the language of processes: P, Q ::= a = M pure () P Q And the following ambient congruence equations: P Q Q P P (Q R) (P Q) R

23 23 Semantics for forkio If we have multiple processes active, pick one of them non-deterministically to move: P P P Q P Q The forkio operation introduces a new process: (forkio P = M) P (pure () = M)

24 24 Semantics for MVars MVars are modelled as a special type of process, identified by a unique name. Values of MVar type merely contain the name of the process, so that putmvar and friends know where to look. P, Q ::= a = M pure () P Q n v n n (putmvar n v = M) v n (pure () = M) v n (takemvar n = M) n (pure v = M)

25 25 Semantics for newmvar We might think that newmvar should have semantics like this: (n fresh) (newmvar v = M) v n (pure n = M) But this approach has a number of problems: The name n is now globally-scoped, without an explicit binder to introduce it. It doesn t accurately model the lifetime of the MVar, which should be garbage-collected once all threads that can access it finish. It makes MVars global objects, so our semantics aren t very abstract. We would like local communication to be local in our model.

26 26 Restriction Operator We introduce a restriction operator ν to our language of processes: P, Q ::= a = M pure () P Q n v n (ν n) P Writing (ν n) P says that the MVar name n is only available in process P. Mentioning n outside P is not well-formed. We need the following additional congruence equations: (ν n) (ν m) P (ν m) (ν n) P (ν n)(p Q) P (ν n) Q (if n / P)

27 Better Semantics for newmvar The rule for newmvar is much the same as before, but now we explicitly restrict the MVar to M. (n fresh) (newmvar v = M) (ν n)( v n (pure n = M)) We can always execute under a restriction: P P (ν n) P (ν n) P Question What happens when you put an MVar inside another MVar? 27

28 28 Garbage Collection If an MVar is no longer used, we just replace it with the do-nothing process: (ν n) n pure () (ν n) v n pure () Extra processes that have outlived their usefulness disappear: pure () P P

29 29 Process Algebra Our language P is called a process algebra, and our method of ascribing semantics to P is called structural operational semantics. Neither are a focus of this course, but they are points which intersect heavily with other courses at UNSW. Process algebras and calculi of various kinds are covered in great detail in COMP6752 with Rob van Glabbeek, who is an expert in this field. Operational Semantics are a major part of the course COMP[39]161, which I develop and teach along with Gabi Keller, who is the lecturer in charge. If there s time! We can talk about CCS.

30 30 Bibliography Simon Marlow Parallel and Concurrent Programming in Haskell O Reilly, Simon Peyton Jones, Andrew Gordon and Sigbjorn Finne Concurrent Haskell POPL 96 Association for Computer Machinery Simon Marlow (Editor) Haskell 2010 Language Report