A student asked in lecture why locks do not (always) provide isolation. The simple answer is that locks do not prevent other threads from reading partial results occurring in a critical section. Transactional memory delivers a finer grain of concurrency as opposed to locks. It considers concurrency/conflicts between memory addresses as opposed to creating a strict critical section of instructions.
@rubensan, so I think locks can guarantee atomicity, but not isolation, right?
@nian, I don't believe so? Consider the case where a thread fails midway through a critical section. When using locks, the results are partially committed when it shouldn't be. Transactions would restart the process.
My impression was that locks can guarantee atomicity if we can catch any exceptions and undo results/unlock if there is a failure, like easy versioning.
Please log in to leave a comment.
This has some similarities with database transactions and their ACID property. I think Transactional memory only provides ACI and not D (durability) since the data in memory (volatile) is lost on system crash. So the TM ACI property can be seen as:
Atomicity: Operations in the transaction commit or abort together. No partial commit or abort. Its all or nothing.
Consistency: All the processors see the same data in memory. If processor A sees 10 in address X then processor B will also see 10 in address X. Obviously, this excludes the processor currently manipulating the content of the address.
Isolation: Here transactional memory differs from database transactions. Database supports multiple isolation levels, but I think here we only support something similar to the database "read committed" isolation level. So in TM, we can only read committed data, hence no dirty reads.