Programming Idioms for Transactional Events

Many concurrent programming models enable both transactional memory and message passing. For such models, researchers have built increasingly efficient implementations and defined reasonable correctness criteria, while it remains an open problem to obtain the best of both worlds. We present a programming model that is the first to have opaque transactions, safe asynchronous message passing, and an efficient implementation. Our semantics uses tentative message passing and keeps track of dependencies to enable undo of message passing in case a transaction aborts. We can program communication idioms such as barrier and rendezvous that do not deadlock when used in an atomic block. Our experiments show that our model adds little overhead to pure transactions, and that it is significantly more efficient than Transactional Events. We use a novel definition of safe message passing that may be of independent interest.

show abstract

“…The service can simply be provision of unique ids [14]. A generic function (serverLoop) is offered in [14] to create servers.…”

Section: Benchmarks and Platformmentioning

confidence: 99%

Communicating memory transactions

LesaniMohsen

PalsbergJens

2011

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…A generic function (serverLoop) is offered in [14] to create servers. Employing Transactors, we provide a generic class (Server) that can be extended to create servers.…”

Section: Benchmarks and Platformmentioning

confidence: 99%

“…We adopt the Server benchmark that is independently explained by [20] as the Vacation Reservation, by [14] as the Server Loop programming idiom and by [21] as the Job Handling system. A server thread handles requests from client threads.…”

Section: Benchmarks and Platformmentioning

confidence: 99%