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

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

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
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
Channels are created inside events
Example
newSChan :: Evt (SChan a)
main = do
c <- sync newSChan;
forkIO (sync (recvEvt c));
sync (sendEvt c 0)

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