If I understand correctly, there is a functional difference between transactional memory techniques like atomic and more heavier weight synchronized. Using the transactional memory, we can make the memory operation in the critical session atomic, isolated, and serializable. But for the IO operations, it can be problematic because the IO may not support redo or undo. IO devices like disks may have similar interfaces as memory, but for other devices (especially character devices) like networks, printers may not. For example, there is no command for ATMs to recall banknotes or command for servers to recall an email. So I think the transaction memory is only helpful for memory transactions, and we still need mechanisms like locks to make IO be synchronized.
harlenVII
When failure happens, transaction is aborted and memory updates are undone. Do we need a lock to undo previous changes? What if other threads modify the same memory address at the same time?
sreevisp
@harlenVII: If we were to handle exceptions ourselves, then yes, we would need exclusive access to the data in order to undo our changes (especially since failures in this scenario are most likely caused by conflicting accesses). But then we would also have to somehow ensure that these are done before any other threads get access to the data, and synchronizing this behavior is a nontrivial problem in itself. The idea on this slide is that we give the responsibility of handling exceptions to the system in order to avoid dealing with these issues.
jedi
@pagerank, you could perform the actual I/O operation on a copy/new location and only switch over the file pointer to point to the modified location in the filesystem when the transaction is committed...
If I understand correctly, there is a functional difference between transactional memory techniques like atomic and more heavier weight synchronized. Using the transactional memory, we can make the memory operation in the critical session atomic, isolated, and serializable. But for the IO operations, it can be problematic because the IO may not support redo or undo. IO devices like disks may have similar interfaces as memory, but for other devices (especially character devices) like networks, printers may not. For example, there is no command for ATMs to recall banknotes or command for servers to recall an email. So I think the transaction memory is only helpful for memory transactions, and we still need mechanisms like locks to make IO be synchronized.
When failure happens, transaction is aborted and memory updates are undone. Do we need a lock to undo previous changes? What if other threads modify the same memory address at the same time?
@harlenVII: If we were to handle exceptions ourselves, then yes, we would need exclusive access to the data in order to undo our changes (especially since failures in this scenario are most likely caused by conflicting accesses). But then we would also have to somehow ensure that these are done before any other threads get access to the data, and synchronizing this behavior is a nontrivial problem in itself. The idea on this slide is that we give the responsibility of handling exceptions to the system in order to avoid dealing with these issues.
@pagerank, you could perform the actual I/O operation on a copy/new location and only switch over the file pointer to point to the modified location in the filesystem when the transaction is committed...