atomic

{

//do stuff - if failure, then throw ex out

//of block, roll back - this is a transaction...

}



/*next code fragment... So, code flow appears sequential to the programmer(as we would expect), even though under the covers it is of course not always processing sequentially*/









[My apologies for the somewhat shaky camera work. This conversation took place shortly after the terrorist scare at London's Heathrow airport (I had to leave some of my camera equipment in New Delhi)]

Recently, we visited MSR Cambridge(UK) to meet some of the great minds working there. In this case, we were fortunate enough to get an hour's time with Simon Peyton-Jones and Tim Harris , who are researchers working on a very hard problem: making it easier (more predictable, more reliable, more composable) to write concurrent applications in this the age of Concurrency (multi-core is a reality, not a dream).Specifically, Simon and Tim (and team) are working on a programming technology called Software Transactional Memory (STM) which provides an elegant, easy to use language-level abstraction for writing concurrent applications that is based on widely-understood conceptual constructs like Atomic operations (and, well, Transactions...). Simon, Tim and team do all the nasty locking work for you. With STM-enabled languages, you can just concentrate on the algorithms at hand and leave the low-level heavy lifting to the sub-system. Sound familiar?So, imagine this:Read scientific papers here Play with STM here and here