Transactional Events

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

2. A New High-Level Abstraction Mechanism • Key Idea: Atomicity can enhance the expressive power of first-class synchronous message passing • Transactional events enable elegant and simple solutions to interesting problems

3. 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 }

4. 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

5. 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)

6. Transactional Event Monad • 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

7. 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

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

9. 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)

10. 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 }

11. 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 }

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

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

14. 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.

15. 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

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