Software Transactional Memory

I saw an interesting tech talk recently by someone from Intel on their work on Software Transactional Memory. A question from the audience pointed out an interesting problem with exceptions (also discussed under "Implementation issues" in the Wikipedia article). In STM threads perform optimistic reads, and are retried at commit time if conflicts are detected. Because the reads are "dirty" inconsistent states may be seen, and null pointer or division by zero exceptions may be thrown. The application programmer must recognize this possibility and distinguish between transient (should be retried) and fatal errors. STM trades off the complexity of locking with the complexity of understanding the effects of inconsistent reads. Opposite to the suggestion in Wikipedia, perhaps the system could check for conflicts at the point of exception, and automatically retry if one is found. Of course STM still doesn't work for non-restartable operations, such as I/O. I find the ACID (Atomic, Consistent, Isolated, Durable) status of STM transactions debatable (and advocates don't claim to satisfy all of them).