Transactional Events Kevin Donnelly, Boston University Matthew Fluet, Cornell University (now TTI Chicago) ICFP’06

A New High-Level Abstraction Mechanism Transactional Events = First-class SynchronousMessage-Passing + Atomic Transactions Key Idea: Atomicity can enhance the expressive power of first-class synchronous message passing Transactional events enable elegant and simple solutions to interesting problems

What Transactional Events Can Do Transactional events allow for modular implementations where protocols are otherwise needed e.g. guarded synchronous receive Transactional events allow more powerful abstractions e.g. 3-way swap channels Transactional events allow easier reasoning about sequential composition under non-deterministic choice atomically { read x from c; if g x then return x else rollback }

Outline Comparison to transactional shared memory Features of Transactional Events synchronous message passing, synchronous choice and atomic sequencing guarded receive, 3-way swap Other Details handling exception, implementation, downsides

Atomicity and Isolation Shared memory transactions provide both atomicity and isolation atomicity: Transactions either complete and commit or rollback (intermediate states are not visible) isolation: Interleavings that are not serializable cause transaction failure (interleavings are not visible)

Transactional Event Monad Events are quiescent until triggered with `sync` data Evt a alwaysEvt :: a -> Evt a (return) thenEvt :: Evt a -> (a -> Evt b) -> Evt b (>>=) sync :: Evt a -> IO a

Synchronous Message Passing Messages are passed over channels Sender blocks for matching receiver data SChan a sendEvt :: SChan a -> a -> Evt () recvEvt :: SChan a -> Evt a

Synchronous Message-Passing Channels are created inside events Example newSChan :: Evt (SChan a) main = do c <- sync newSChan; forkIO (sync (recvEvt c)); sync (sendEvt c 0)

Atomicity Sequencing of events is atomic Example: disjunctive splitting thread1 = sync do { x <- recvEvt c1; sendEvt c2 x } thread2 = sync (sendEvt c1 0) thread3a = sync (recvEvt c1) thread3b = sync (recvEvt c2)

Non-deterministic choice Symmetric non-deterministic choice Example chooseEvt :: Evt a -> Evt a -> Evt a neverEvt :: Evt a recvEvt c `chooseEvt` do { sendEvt c 0; return 0 }

Communication Sequences and Non-deterministic Choice Without atomicity, need single-communication commit point c1; c2; …; ci; ci+1; …; cn With atomicity, chooseEvt does not commit to one branch unless the transaction commits pre-commit post-commit commit point do { _ <- recvEvt c; recvEvt c } `chooseEvt` do { sendEvt c 0; return 0 }

Guarded Receive grecvEvt :: (a -> Bool) -> SChan a -> Evt a grecvEvt g c = do x <- recvEvt c; if g x then return x else neverEvt

Triple Swap Channels type TriSChan a newTriSChan :: Evt (TriSChan a) swapEvt :: TriSchan a -> a -> Evt (a, a)

Triple Swap type TriSChan a = SChan (a, SChan (a, a)) swapEvt :: TriSChan a -> a -> (a, a) swapEvt ch x1 = client ` chooseEvt` leader where client = do { rCh <- newSChan; sendEvt ch (x1, rCh); recvEvt rCh } leader = do { (x2, rCh2) <- recvEvt ch; (x3, rCh3) <- recvEvt ch; sendEvt rCh2 (x3, x1); sendEvt rCh3 (x1, x2); alwaysEvt (x2, x3) } Not possible with first-class synchronous message-passing alone.

Other Details Exceptions reaching the top of a transaction cause rollback motivated by desire to preserve mutual-commitment properties Can encode both CML-like events and transactional shared memory Implementation as a library for GHC see paper for details Downsides Easy to get exponential behavior if you are not careful

Conclusion Atomicity can add power to first-class synchronous message-passing more flexible composition cooperation without protocols more powerful synchronization