Abstract

Over the last few years we’ve been working on the design and implementation of “atomic” blocks as an alternative to mutual exclusion locks for concurrency control in shared memory multi-threaded programs.

In this talk I’ll discuss some of the surprising challenges we’ve found in what appeared to be a simple part of this work: defining the semantics of programs using atomic blocks.

For example, what happens if a program accesses a shared object inside an atomic block and, at the same time, accesses it in ordinary code? What if an atomic block is used to make a shared object private to a thread which then accesses it without any concurrency control? What happens if an optimizing compiler writer wants to combine adjacent atomic blocks into a larger one?

As I’ll discuss, deciding how to answer these questions seems to involve a trade off between performance, a programming model with “no surprises”, and a programming model where data can be shared between ordinary accesses and accesses within atomic blocks.