haskell concurrency and stmcs3161/19t3/week 10/2fri/slides.pdf · haskell concurrency and stm liam...
TRANSCRIPT
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
9
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
10
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
102
20
3 22
11
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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 Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
The Problem with Locks
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
The Problem with Locks
Assume some infrastructure for accounts:
type Balance = Inttype 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)
21
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
The Problem with Locks
Assume some infrastructure for accounts:
type Balance = Inttype 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)
22
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
The Problem with Locks
Assume some infrastructure for accounts:
type Balance = Inttype 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)
23
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
Attempt #1
transfer f t m = do withdraw f m; deposit t m
24
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
Attempt #2
transfer f t m = dofb ← takeMVar ftb ← takeMVar tputMVar t (tb + m)putMVar f (fb −m)
26
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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?
30
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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?
31
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
33
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
34
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
35
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
36
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
37
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
38
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
39
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
44
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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.
45
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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?
47
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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? We re-run the transaction!Liam: Demonstrate!
48
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
MyExperience
https://myexperience.unsw.edu.au
(one participation mark is contingent on this)60
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
66
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
Semantics for forkIO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
Semantics for forkIO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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)
70
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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)
71
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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?
76
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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?
77
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Readers and Writers Haskell Issues with Locks Software Transactional Memory Wrap-up Bonus: Semantics for IO
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
Association for Computer Machinery
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
Association for Computer Machinery
http://transact2014.cse.lehigh.edu/yates.pdf
82