Participant provided links and papers
http://research.microsoft.com/~tharris/.
http://research.microsoft.com/~tharris/papers/2004-csjp.pdf -- design
issues for atomic blocks in safe programming languages
http://research.microsoft.com/~tharris/papers/2005-ppopp-composable.pdf --
current ideas about blocking and composition.
C. Scott Ananian, Krste Asanovic, Bradley C. Kuszmaul, Charles E. Leiserson
and Sean Lie,
"Unbounded Transactional Memory"
http://bradley.csail.mit.edu/~bradley/xaction.pdf
Sean Lie, "Hardware Support for Unbounded Transactional Memory"
Master's Thesis, MIT, May 2004
http://supertech.csail.mit.edu/papers/lie-thesis.pdf
Kai Huang, "Data-Race Detection in Transactions-Everywhere Parallel
Programming"
Master's Thesis, MIT, June 2003
http://supertech.csail.mit.edu/papers/thesis-kai.pdf
http://www.cs.washington.edu/homes/djg/slides/intel_psl_05.ppt
AtomCaml: First-class Atomicity via Rollback
Michael F. Ringenburg and Dan Grossman
{miker,djg}@cs.washington.edu}
ABSTRACT
We have designed, implemented, and evaluated AtomCaml, an extension to Objective
Caml that provides a synchronization primitive for atomic (transactional)
execution of code. A first-class primitive function of type (unit->'a)->'a
evaluates its argument (which may call other functions, even external C
functions) as though no other thread had interleaved execution. Our design
ensures fair scheduling and obstruction-freedom. Our implementation extends the
Objective Caml bytecode compiler and run-time system to support atomicity. A
logging-and-rollback approach lets us undo uncompleted atomic blocks upon thread
pre-emption, and retry them when the thread is rescheduled. The mostly
functional nature of Caml code and Objective Caml's commitment to a
uniprocessor execution model allow particularly efficient logging. We have
evaluated the efficiency and ease-of-use of AtomCaml by writing libraries
and microbenchmarks, writing a small application, and replacing all
locking with atomicity in an existing, large multithreaded application.
Our experience indicates the performance overhead is negligible, atomic
helps avoid synchronization mistakes, and idioms such as condition
variables adapt reasonably to the atomic approach.
^M