haskell concurrency and stmcs3161/19t3/week 10/2fri/slides.pdf · haskell concurrency and stm liam...

Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO

Haskell Concurrency and STM

Liam O’ConnorCSE, UNSW (and data61)

Term 3 2019

1


Shared DataConsider the Readers and Writers problem:

Problem

We have a large data structure (i.e. a structure that cannot beupdated in one atomic step) that is shared between some numberof writers who are updating the data structure and some numberof readers who are attempting to retrieve a coherent copy of thedata 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 anupdate finishes will see that update.

We want to minimise waiting.

2


A Crappy Solution

Treat both reads and updates as critical sections — use any oldcritical section solution (locks, etc.) to sequentialise all reads andwrites to the data structure.

Observation

Updates are atomic and reads are consistent — but reads can’thappen concurrently, which leads to unnecessary contention.

3


A Crappy Solution

Treat both reads and updates as critical sections — use any oldcritical section solution (locks, etc.) to sequentialise all reads andwrites to the data structure.

Observation

Updates are atomic and reads are consistent — but reads can’thappen concurrently, which leads to unnecessary contention.

4


A Better Solution

A more elaborate locking mechanism (condition variables) could beused to to allow multiple readers to read concurrently, but writersare still executed individually and atomically.

Observation

We have atomicity and consistency, and now multiple reads canexecute concurrently. Still, we don’t allow updates to executeconcurrently with reads, to prevent partial updates from beingobserved by a reader.

5


A Better Solution

A more elaborate locking mechanism (condition variables) could beused to to allow multiple readers to read concurrently, but writersare still executed individually and atomically.

Observation

We have atomicity and consistency, and now multiple reads canexecute concurrently. Still, we don’t allow updates to executeconcurrently with reads, to prevent partial updates from beingobserved by a reader.

6


Reading and Writing

Complication

Now suppose we don’t want readers to wait (much) while an updateis performed. Instead, we’d rather they get an older version of thedata structure.

Trick: Rather than update the data structure in place, a writercreates their own local copy of the data structure, and then merelyupdates the (shared) pointer to the data structure to point to theircopy.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 theolder version, but reads that start after get the latest.

7


Persistent Data StructuresCopying is O(n) in the worst case, but we can do better for manytree-like types of data structure.

Example (Binary Search Tree)

64

37

20

3 22

40

102

Pointer

64

37

40

42

8




64

37

20

3 22

40

102

Pointer

64

37

40

42

9




64

37

20

3 22

40

102

Pointer

64

37

40

42

10




64

37

20

3 22

40

102

Pointer

64

37

40

42

102

20

3 22

11


Purely Functional Data Structures

Persistent data structures that exclusively make use of copyingover mutation are called purely functional data structures. Theyare so called because operations on them are best expressed in theform of mathematical functions that, given an input structure,return a new output structure:

insert v Leaf = Branch v Leaf Leafinsert v (Branch x l r) = if v ≤ x then

Branch x (insert v l) relseBranch x l (insert v r)

12


Computing with Functions

We model real processes in Haskell using the IO type. We’ll treatIO as an abstract type for now, and give it a formal semanticslater if we have time:

IO τ =A (possibly effectful) process that, when executed,produces a result of type τ

Note the semantics of evaluation and execution are different things.

13


Building up IORecall monads:

return :: ∀a. a→ IO a(�=) :: ∀a b. IO a→ (a→ IO b)→ IO b

getChar :: IO CharputChar :: Char→ IO ()

Example (Echo)

echo :: IO ()echo = getChar �= (λx . putChar x �= λy . echo)

Or, with do notation:echo :: IO ()echo = do x ← getChar

putChar xecho

14


Adding Concurrency

We can have multiple threads easily enough:

forkIO :: IO () → IO ()

Example (Dueling Printers)

let loop c = do putChar c ; loop cin do forkIO (loop ‘a’); loop ‘z’

But what sort of synchronisation primitives are available?

15


MVars

The MVar is the simplest synchronisation primitive in Haskell. Itcan be thought of as a shared box which holds at most one value.

Processes must take the value out of a full box to read it, andmust put a value into an empty box to update it.

MVar Functions

newMVar :: ∀a. a→ IO (MVar a) Create a new MVartakeMVar :: ∀a. MVar a→ IO a Read/remove the valueputMVar :: ∀a. MVar a→ a→ IO () Update/insert a value

Taking from an empty MVar or putting into a full one results inblocking.An MVar can be thought of as channel containing at most onevalue.

16


Readers and WritersWe can treat MVars as shared variables with some definitions:

writeMVar m v = do takeMVar m; putMVar m vreadMVar m = do v ← takeMVar m; putMVar m v ; return v

problem :: DB → IO ()problem initial = do

db ← newMVar initialwl ← newMVar ()let reader = readMVar db �= · · ·let writer = do

takeMVar wld ← readMVar dblet d ′ = update devaluate d ′

writeMVar db d ′

putMVar wl ()

17


Fairness

Each MVar has an attached FIFO queue, so GHC Haskell canensure the following fairness property:

No thread can be blocked indefinitely on an MVar unlessanother thread holds that MVar indefinitely.

18


The Problem with Locks

Problem

Write a procedure to transfer money from one bank account toanother. To keep things simple, both accounts are held in memory:no interaction with databases is required. The procedure mustoperate correctly in a concurrent program, in which many threadsmay call transfer simultaneously. No thread should be able toobserve a state in which the money has left one account, but notarrived in the other (or vice versa).

19



Assume some infrastructure for accounts:

type Balance = Int

type Account = MVar Balance

withdraw :: Account→ Int→ IO ()withdraw a m = takeMVar a�= (putMVar a ◦ subtract m)

deposit :: Account→ Int→ IO ()deposit a m = withdraw a (−m)

20




type Balance = Inttype Account = MVar Balance



21







22







23


Attempt #1

transfer f t m = do withdraw f m; deposit t m

24


Attempt #1

transfer f t m = do withdraw f m; deposit t m

Problem

The intermediate states where a transaction has only been partiallycompleted are externally observable.

In a bank, we might want the invariant that at all points duringthe transfer, the total amount of money in the system remainsconstant. We should have no money go missinga.

aWe’re not CBA

25


Attempt #2

transfer f t m = dofb ← takeMVar ftb ← takeMVar tputMVar t (tb + m)putMVar f (fb −m)

26


Attempt #2

transfer f t m = dofb ← takeMVar ftb ← takeMVar tputMVar t (tb + m)putMVar f (fb −m)

Problem

We can have deadlock here, when two people transfer to eachother simultaneously and both transfers proceed in lock-step.

Also, not being able to compose our existing withdrawal anddeposit operations is unfortuitous from a software designperspective.

27


SolutionWe should enforce a global ordering of locks.

type Account = (MVar Balance,AccountNo)

transfer (f , fa) (t, ta) m = do(fb, tb)← if fa ≤ ta

then dofb ← takeMVar ftb ← takeMVar tpure (fb, tb)

else dotb ← takeMVar tfb ← takeMVar fpure (fb, tb)

putMVar t (tb + m)putMVar f (fb −m)

28


It Gets Complicated

Problem

Now suppose that some accounts can be configured with a“backup” account that is withdrawn from if insufficient funds areavailable in the normal account.

Should you take the lock for the backup account?

To make life even harder: What if we want to block ifinsufficient funds are available?

29


It Gets Complicated

Problem




30


It Gets Complicated

Problem




31


Conclusion

Lock-based methods have their place, but from a softwareengineering perspective they’re a nightmare.

Remember not to take too many locks.

Remember not to take too few locks.

Remember what locks correspond to each piece of shareddata.

Remember not to take the locks in the wrong order.

Remember to deal with locks when an error occurs.

Remember to signal condition variables and release locks atthe right time.

Most importantly, modular programming becomes impossible.

32


Conclusion









33


Conclusion









34


Conclusion









35


Conclusion









36


Conclusion









37


Conclusion









38


Conclusion









39


The Solution

Represent an account as a simple shared variable containing thebalance.

transfer f t m = atomically $ dowithdraw f mdeposit t m

Where atomically P guarantees:

Atomicity The effects of the action P become visible all at once.

Isolation The effects of action P is not affected by any otherthreads.

Problem

How can we implement atomically?

40


The Global Lock

We can adopt the solution of certain reptilian programminglanguages.

Problem

Atomicity is guaranteed, but what about isolation?Also, performance is predictably garbage.

41


Ensuring Isolation

Rather than use regular shared variables, use special transactionalvariables.

createTVar :: a→ STM (TVar a)readTVar :: TVar a→ STM awriteTVar :: TVar a→ a→ STM ()

atomically :: STM a→ IO a

The type constructor STM is also an instance of the Monad typeclass, and thus supports the same basic operations as IO.

pure :: a→ STM (TVar a)(�=) :: STM a→ (a→ STM b)→ STM b

42


Implementing Accounts

type Account = TVar Int

withdraw :: Account→ Int→ STM ()withdraw a m = do

balance ← readTVar mwriteTVar a (balance −m)

deposit a m = withdraw a (−m)

Observe: withdraw (resp. deposit) can only be called inside anatomically

⇒ We have isolation.

But, we’d still like to run more than one transaction at once —one global lock isn’t good enough.

43







Observe: withdraw (resp. deposit) can only be called inside anatomically ⇒ We have isolation.


44







Observe: withdraw (resp. deposit) can only be called inside anatomically ⇒ We have isolation.


45


Optimistic Execution

Each transaction (atomically block) is executed optimistically.This means they do not need to check that they are allowed toexecute the transaction first (unlike, say, locks, which prefer apessimistic model).

Implementation Strategy

Each transaction has an associated log, which contains:

The values written to any TVars with writeTVar .

The values read from any TVars with readTVar , consultingearlier log entries first.

First the log is validated, and, if validation succeeds, changes arecommitted. Validation and commit are one atomic step.

What can we do if validation fails?

46









What can we do if validation fails?

47









What can we do if validation fails? We re-run the transaction!Liam: Demonstrate!

48


Re-running transactions

atomically $ dox ← readTVar xvy ← readTVar yvif x > y then launchMissiles else pure ()

To avoid serious international side-effects, the transaction must berepeatable. We can’t change the world until commit time.

A real implementation is smart enough not to retry with exactlythe same schedule.

49


Blocking and retry

Problem

We want to block if insufficient funds are available.

We can use the helpful action retry :: STM a.

withdraw ′ :: Account→ Int→ STM ()withdraw ′ a m = do

balance ← readTVar mif m > 0 && m > balance then

retryelse

writeTVar a (balance −m)

50


Blocking and retry

Problem

We want to block if insufficient funds are available.

We can use the helpful action retry :: STM a.

withdraw ′ :: Account→ Int→ STM ()withdraw ′ a m = do

balance ← readTVar mif m > 0 && m > balance then

retryelse

writeTVar a (balance −m)

51


Choice and orElse

Problem

We want to transfer from a backup account if the first account hasinsufficient funds, and block if neither account has insufficientfunds.

We can use the helpful action

orElse :: STM a→ STM a→ STM a

wdBackup :: Account→ Account→ Int→ STM ()wdBackup a1 a2 m = orElse (withdraw ′ a1 m) (withdraw ′ a2 m)

52


Choice and orElse

Problem

We want to transfer from a backup account if the first account hasinsufficient funds, and block if neither account has insufficientfunds.

We can use the helpful action

orElse :: STM a→ STM a→ STM a

wdBackup :: Account→ Account→ Int→ STM ()wdBackup a1 a2 m = orElse (withdraw ′ a1 m) (withdraw ′ a2 m)

53


Evaluating STM

STM is modular. We can compose transactions out of smallertransactions. We can hide concurrency behind library boundarieswithout worrying about deadlock or global invariants.

Lock-free data structures and transactional memory based solutionswork well if contention is low and under those circumstances scalebetter to higher process numbers than lock-based ones.

Most importantly, the resulting code is often simpler and morerobust. Profit!

54


Progress

One transaction can force another to abort only when itcommits.

At any time, at least one currently running transaction cansuccessfully commit.

Traditional deadlock scenarios are impossible, as is cyclic restartingwhere two transactions constantly cancel each other.

Starvation is possible (when?), however uncommon in practice. So,we technically don’t have eventual entry.

55


Performance

A concurrent channel using STM was implemented and comparedto an MVar version. The STM version performs within 10% of theMVar version, and uses half of the heap space −→ Profit! 1

The implementation is a bit simpler as well. Let’s do it if we have time!

Just a linked list, really.

1Mostly, the MVar implementation performed poorly due to lots ofoverhead to make it exception-safe.

56


Database Guarantees

Atomicity X Each transaction should be ‘all or nothing’.

Consistency X Each transaction in the future sees the effects oftransactions in the past.

Isolation X The transaction’s effect on the state cannot beaffected by other transactions.

Durability The transaction’s effect on the state survives poweroutages and crashes.

STM gives you 75% of a database system. The Haskell packageacid-state builds on STM to give you all four.

57


Hardware Transactional MemoryThe latest round of Intel processors support HardwareTransactional Memory instructions:

XBEGIN Begin a hardware transaction

XEND End a hardware transaction

XTEST Test if currently executing a transaction.

XABORT Abort the transaction and jump to the abort handler.

The “log” we described earlier is stored in L1 cache. Speculativewrites are limited to the amount of cache we have. If a speculativeread overflows the cache, it may sometimes generate a spuriousconflicts and cause the transaction to abort.

For this reason, progress can only be ensured through thecombination of STM and HTM. Work is currently underway toimplement this for Haskell, and prototypes show promisingperformance improvements.

58


That’s it

We have now covered all the content in COMP3161/COMP9164.Thanks for sticking with the course.

Syntax FoundationsConcrete/Abstract Syntax, Ambiguity, HOAS, Binding,Variables, Substitution, λ-calculus

Semantics FoundationsStatic Semantics, Dynamic Semantics (Small-Step/Big-Step),Abstract Machines, Environments, Stacks, Safety, Liveness,Type Safety (Progress and Preservation)

FeaturesAlgebraic Data Types, Recursive TypesExceptionsPolymorphism, Type Inference, UnificationOverloading, Subtyping, Abstract Data TypesConcurrency, Critical Sections, STM

59


MyExperience

https://myexperience.unsw.edu.au

(one participation mark is contingent on this)60

https://myexperience.unsw.edu.au


Further LearningUNSW courses:

COMP3141 — Software System Design and ImplementationCOMP6721 — (In-)formal MethodsCOMP3131 — CompilersCOMP4141 — Theory of ComputationCOMP6752 — Modelling Concurrent SystemsCOMP3151 — Foundations of ConcurrencyCOMP4161 — Advanced Topics in VerificationCOMP3153 — Algorithmic Verification

Online LearningOregon Programming Languages Summer School Lectures(https://www.cs.uoregon.edu/research/summerschool/archives.html) Videos are available from here! Also someon YouTube.Bartosz Milewski’s Lectures on Category Theory are onYouTube.

Books — see my newly published Book List!

61

https://www.cs.uoregon.edu/research/summerschool/archives.html

https://www.cs.uoregon.edu/research/summerschool/archives.html


What’s next?

The exam is on Saturday, 30th of November 2019 (sorry) at08:45am (also sorry).

Consult exam timetable for location (Scientia for UG,Mathews for PG)

It runs for 2 hours.

You are allowed two single-sided sheets of handwrittennotes.

I plan to post additional revision questions soon. We will have arevision lecture on Monday where we go through the sampleexam.

62


Evaluation Semantics

The semantics of Haskell’s evaluation are interesting but notparticularly relevant for us. We will assume that it happens quietlywithout 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 thefollowing extra equations, justified by the monad laws:

return N �= M ≡ M N(X �= Y )�= Z ≡ X �= (λx . Y x �= Z )X ≡ X �= return

63


Processes

This means that a Haskell expression of type IO τ for will boildown to either return x where x is a value of type τ ; or a�= Mwhere a is some primitive IO action (forkIO p, readMVar v , etc.)and M is some function producing another IO τ . This is the headnormal 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 theseprocesses. Let’s use operational semantics:

(7→) ⊆ P × P

64


Semantics for forkIO

To model forkIO, we need to model the parallel execution ofmultiple processes in our process language. We shall add a parallelcomposition operator to the language of processes:

P,Q ::= a�= M| return ()| P ‖ Q| · · ·

And the following ambient congruence equations:

P ‖ Q ≡ Q ‖ PP ‖ (Q ‖ R) ≡ (P ‖ Q) ‖ R

65



To model forkIO, we need to model the parallel execution ofmultiple processes in our process language. We shall add a parallelcomposition operator to the language of processes:

P,Q ::= a�= M| return ()| P ‖ Q| · · ·

And the following ambient congruence equations:

P ‖ Q ≡ Q ‖ PP ‖ (Q ‖ R) ≡ (P ‖ Q) ‖ R

66



If we have multiple processes active, pick one of themnon-deterministically to move:

P 7→ P ′

P ‖ Q 7→ P ′ ‖ Q

The forkIO operation introduces a new process:

(forkIO P �= M) 7→ P ‖ (return ()�= M)

67



If we have multiple processes active, pick one of themnon-deterministically to move:

P 7→ P ′

P ‖ Q 7→ P ′ ‖ Q

The forkIO operation introduces a new process:

(forkIO P �= M) 7→ P ‖ (return ()�= M)

68


Semantics for MVars

MVars are modelled as a special type of process, identified by aunique name. Values of MVar type merely contain the name ofthe process, so that putMVar and friends know where to look.

P,Q ::= a�= M| return ()| P ‖ Q| 〈〉n | 〈v〉n| · · ·

〈〉n ‖ (putMVar n v �= M) 7→ 〈v〉n ‖ (return ()�= M)

〈v〉n ‖ (takeMVar n�= M) 7→ 〈〉n ‖ (return v �= M)

69


Semantics for MVars





70


Semantics for MVars





71


Semantics for newMVar

We might think that newMVar should have semantics like this:

(newMVar v �= M) 7→ 〈v〉n ‖ (return n�= M)(n fresh)

But this approach has a number of problems:

The name n is now globally-scoped, without an explicit binderto introduce it.

It doesn’t accurately model the lifetime of the MVar, whichshould be garbage-collected once all processes that can accessit finish.

It makes MVars global objects, so our semantics aren’t veryabstract. We would like local communication to be local inour model.

72


Restriction Operator

We introduce a restriction operator ν to our language of processes:

P,Q ::= a�= M| return ()| P ‖ Q| 〈〉n | 〈v〉n| (ν n) P

Writing (ν n) P says that the MVar name n is only available inprocess P. Mentioning n outside P is not well-formed. We needthe following additional congruence equations:

(ν n) (ν m) P ≡ (ν m) (ν n) P(ν n)(P ‖ Q) ≡ P ‖ (ν n) Q (if n /∈ P)

73


Restriction Operator

We introduce a restriction operator ν to our language of processes:

P,Q ::= a�= M| return ()| P ‖ Q| 〈〉n | 〈v〉n| (ν n) P

Writing (ν n) P says that the MVar name n is only available inprocess P. Mentioning n outside P is not well-formed. We needthe following additional congruence equations:

(ν n) (ν m) P ≡ (ν m) (ν n) P(ν n)(P ‖ Q) ≡ P ‖ (ν n) Q (if n /∈ P)

74


Better Semantics for newMVar

The rule for newMVar is much the same as before, but now weexplicitly restrict the MVar to M.

(newMVar v �= M) 7→ (ν n)(〈v〉n ‖ (return n�= M))(n fresh)

We can always execute under a restriction:

P 7→ P ′

(ν n) P 7→ (ν n) P ′

Question

What happens when you put an MVar inside another MVar?

75






P 7→ P ′

(ν n) P 7→ (ν n) P ′

Question


76






P 7→ P ′

(ν n) P 7→ (ν n) P ′

Question


77


Garbage Collection

If an MVar is no longer used, we just replace it with the do-nothingprocess:

(ν n) 〈〉n 7→ return ()(ν n) 〈v〉n 7→ return ()

Extra processes that have outlived their usefulness disappear:

return () ‖ P 7→ P

78


Garbage Collection

If an MVar is no longer used, we just replace it with the do-nothingprocess:

(ν n) 〈〉n 7→ return ()(ν n) 〈v〉n 7→ return ()

Extra processes that have outlived their usefulness disappear:

return () ‖ P 7→ P

79


Process Algebra

Our language P is called a process algebra, a common means ofdescribing semantics for concurrent programs.Process algebras and calculi of various kinds are covered in greatdetail in COMP6752 with Rob van Glabbeek, who is an expert inthis field.The last topic of this course is Software Transactional Memory,which we will cover in Week 12.

If there’s time!

We can talk about more concurrency topics.

80


Bibliography

Simon Marlow

Parallel and Concurrent Programming in Haskell

O’Reilly, 2013

http://chimera.labs.oreilly.com/books/1230000000929

Simon Peyton Jones, Andrew Gordon and Sigbjorn Finne

Concurrent Haskell

POPL ’96

Association for Computer Machinery

http://microsoft.com/en-us/research/wp-content/uploads/1996/01/concurrent-haskell.pdf

Simon Marlow (Editor)

Haskell 2010 Language Report

https://www.haskell.org/onlinereport/haskell2010/

81

http://chimera.labs.oreilly.com/books/1230000000929

http://microsoft.com/en-us/research/wp-content/uploads/1996/01/concurrent-haskell.pdf

https://www.haskell.org/onlinereport/haskell2010/


BibliographySimon Peyton Jones

Beautiful Concurrency

In “Beautiful Code”, ed. Greg Wilson, O’Reilly, 2007

http://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/beautiful.pdf

Tim Harris, Simon Marlow, Simon Peyton Jones, Maurice Herlihy

Composable Memory Transactions

PPoP ’05


www.microsoft.com/en-us/research/wp-content/uploads/2005/01/2005-ppopp-composable.pdf

David Himmelstrup

Acid-State Library

https://github.com/acid-state/acid-state

Ryan Yates and Michael L. Scott

A Hybrid TM for Haskell

TRANSACT ’14


http://transact2014.cse.lehigh.edu/yates.pdf

82

http://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/beautiful.pdf

http://www.microsoft.com/en-us/research/wp-content/uploads/2005/01/2005-ppopp-composable.pdf

https://github.com/acid-state/acid-state

http://transact2014.cse.lehigh.edu/yates.pdf

haskell concurrency and stmcs3161/19t3/week 10/2fri/slides.pdf · haskell concurrency and stm liam...

Documents